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I.  introduction 


The  Graphics  and  Video  Laboratory  of  the  Department  of  Computer  Science  at  the 
Naval  Postgraduate  School  permits  the  researcher  to  create  three-dimensional  visual 
simulations  from  digital  terrain  data  [Ref.  1].  Specialized  graphics  hardware  allows  die 
display  of  such  simulations  in  near-real  time.  The  goal  of  a  good  part  of  the  work  in  die 
lab  is  the  creation  of  a  movie-like  view  of  movement  over  and  on  terrain,  with 
increasingly  complex  movement  animation  models.  Such  projects  have  strained  the 
equipment’s  capabilities.  One  method  of  increasing  available  computing  power  is  to 
harness  multiple  heterogeneous  machines  together  in  some  distributed  computing 
organization.  It  requires  communication  between  the  various  machines,  as  well  as 
carefully  matching  each  machine’s  capabilities  to  its  assigned  tasks. 

A.  Problem 

Rapid  turnover  of  inexperienced  students  at  the  Naval  Postgraduate  School  makes 
the  creation  of  complex  simulations  difficult  to  manage.  The  learning  curve  becomes 
steeper  as  the  lab’s  capabilities  increase.  One  of  the  areas  of  difficulty  has  been  inter¬ 
computer  communications.  So  much  time  has  been  spent  on  designing,  coding,  and 
debugging  communication  software,  little  has  been  left  for  the  original  research.  We  set 
out  to  provide  an  easy-to-use,  yet  powerful,  set  of  tools  to  aid  in  the  development  of 
multi-computer  projects. 

1.  Approach 

A  communication  protocol  can  be  optimized  for  large  data  transfers,  or  small 
data  transfers,  or  both.  Efforts  to  optimize  for  both  are  both  complex  and  difficult 
[Refs.  2, 3].  File  transfer  protocols  such  as  FTP  in  the  Defense  Advanced  Research 
Project  Agency  (DARPA)  Internet  domain  and  uucp  in  the  UNIX  domain  can  be  used  for 


I 
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large  data  transfers.  Their  overhead1  is  high.  This  overhead  cannot  be  tolerated  in  a 
real-time  problem2.  Our  visual  simulation  efforts  rely  on  small  data  transfers  to 
communicate  among  machines.  These  small  messages  are  typically  commands  and 
changing  status  indicators.  Transferring  the  entire  “world  view"  is  only  a  reasonable  task 
during  initialization  or  reset.  Hence,  we  designed  our  protocols  for  small  messages. 

2.  Design  Criteria 

The  design  criteria  for  developed  protocols  were  simplicity,  ease  of  use, 
portability,  and  efficiency.  Rapid  turnover  of  inexperienced  students  at  the  Naval 
Postgraduate  School  makes  simplicity  of  paramount  importance.  Inevitably,  changes 
will  be  required  and  only  a  simple  protocol  is  easily  modified  to  take  advantage  of  new 
capabilities.  Much  the  same  argument,  and  generally  good  software  design  practice, 
make  ease  of  use  only  slightly  less  important.  Almost  all  operating  system-level  aspects 
are  hidden  from  the  application.  The  number  of  other  machines  to  be  connected  to,  a  use 
of  dynamic  memory  allocation,  and  the  names  of  the  other  machines  are  the  only 
concerns  for  the  application  setting  up  a  connection.  The  synchronization,  or  lack 
thereof,  in  communication  between  machines  is  a  design  decision. 

Portability  dictated  our  use  of  TCP/IP,  an  integral  part  of  the  Defense  Data 
Network  (DDN).  Efficient  use  of  processor  power  was  considered  more  important  than 
efficient  use  of  the  network  resources.  The  network  is  shared  by  the  entire  Computer 
Science  Department,  but  is  not  heavily  loaded. 


1  The  cost  of  creating  a  file  and  then  spawning  a  process  to  send  it  is  high.  On  the  receiving  end,  there  is  the  cost 
of  creating  the  file  and  then  reading  it.  Even  a  zero-cost  file  transfer  protocol  will  require  all  this  oveihead. 

2  Large  data  transfers,  in  real-time  systems,  will  not  be  possible  until  100  MByte/Sec  networks  are  commonly 
available. 


B.  Background 
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1.  Visual  Simulation 

a.  Vision  and  Information  Presentation 

The  eye  has  the  largest  bandwidth  of  any  human  sensory  organ.  Proper 
use  of  this  capability  is  a  challenge  to  all  scientists.  Static  graphs  are  used  in  most 
disciplines  to  show  the  relationships  between  a  limited  number  of  variables.  These  two- 
dimensional  representations  convey  information  more  readily  to  human  beings  than 
would  a  table  of  the  underlying  numbers.  [Ref.  4:  pp.  8-12] 

Time,  a  common  independent  variable,  is  often  one  dimension  on  a  graph. 
The  other  dimension  is  a  single  dependent  variable.  To  portray  additional  variables  in 
one  presentation  is  a  frequently  occurring  requirement.  Various  techniques  such  as 
multiple  colored  lines,  multiple  icons,  and  perspective  drawing  are  used.  With  each 
technique,  only  a  few  additional  variables  are  added  before  the  graph  becomes 
incomprehensible. 

Pictures,  particularly  those  in  color,  have  a  dense  information  content. 
Unless  blind,  we  live  in  a  world  of  pictures.  Human  beings  can  recognize  many 
differences  between  two  similar  pictures.  One  presentation  portrays  many  different 
variables.  When  a  series  of  pictures  are  presented,  the  time  variable  is  easily  correlated 
to  the  actual  time  of  presentation.  When  a  series  of  pictures  is  presented  rapidly,  die 
experience  approaches  reality,  partly  explaining  the  success  of  moving  pictures  and 
television. 


Animation  creates  visual  images  with  an  explicit  time  dimension,  in 
addition  to  two  or  three  spatial  dimensions.  Using  actual  time  to  portray  the 
experimental  time  variable  allows  at  least  one  more  dependent  variable  on  the  display. 
Images  can  be  as  simple  as  a  changing  graph,  or  as  complex  as  a  feature-length  cartoon. 
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However,  animation  creates  its  effect  with  the  playback  of  prerecorded  scenes  [Ref.  5]. 
It  is  not  suitable  for  providing  immediate  feedback  to  a  researcher. 

b.  Definition 

Visual  simulation  is  the  creation,  by  computer,  of  a  realistic,  easily- 
modified,  moving  image  from  the  mathematical  model  of  a  phenomenon.  Realism 
implies  high-resolution,  color  graphics.  Movement  implies  adequate  floating  point 
calculation  capacity  to  recalculate  the  model  and  its  graphical  representation  between 
display  refresh  cycles.  Easy  modification  implies  a  well-designed  computer  application. 

Visual  simulation  allows  a  researcher  to  experiment  easily  with  his 
subject.  Ideally,  we  display  a  realistic  approximation  of  part  of  the  world.  The 
experimenter  then  manipulates  some  part  of  this  visual  simulation  and  receives 
immediate  visual  feedback.  The  rapidly  refreshed  display  is  one  key  to  visual  realism. 
Such  a  display  allows  the  direct  manipulation  of  the  visual  simulation,  making  it  easy 
and  intuitive  to  use  [Ref.  6].  Ease  of  use  allows  the  researcher  to  concentrate  on  the 
research  question,  not  the  display  methodology  or  the  computer  interface. 

c.  Examples 

Recent  visual  simulation  projects  of  the  Graphics  and  Video  Laboratory 
include  speed  control  of  autonomous  vehicles  [Ref.  7],  control  of  autonomous  walking 
machines  [Ref.  8],  rule-based  control  of  autonomous  underwater  vehicles  [Ref.  9], 
interactive  moving  platforms  [Ref.  10]  and  combat  vehicle  control  [Ref.  11].  Each  of 
these  projects  exceeded  the  capacity  of  a  single  workstation.  The  speed  control  and 
interactive  moving  platform  projects,  written  entirely  in  C,  used  two  Silicon  Graphics, 
Inc.  IRIS  workstations,  allowing  multiple  simultaneous  views.  The  other  projects  all 
required  a  rule-based  artificial  intelligence  component,  best  programmed  in  Lisp  for  ease 
of  modification.  Running  the  Lisp  subsystem  on  the  IRIS  workstation  gave  an 
unacceptably  low  refresh  rate  and  correspondingly  poor  realism  [Ref.  12].  Placing  die 


Lisp  subsystem  on  another  machine  improved  the  refresh  rate  of  the  IRIS  workstation 
used  for  the  graphics  display. 

2.  Computer  System  Architecture 

Computer  systems  can  have  a  distributed  or  a  non-distributed  architecture. 
Distributed  architectures  have  only  one  characteristic  in  common,  more  than  one 
processor  used  to  accomplish  the  task.  Beyond  this,  many  different  approaches  have 
been  tried  [Ref.  13].  Identical  processors  give  a  homogeneous  architecture.  Different 
processors  give  a  heterogeneous  architecture.  Either  distributed  architecture  may 
incorporate  shared  memory  or  it  may  not.  The  separate  processors  can  be  closely  or 
loosely  coupled.  Communication  between  processors  can  be  via  shared  memory, 
common  bus,  or  some  form  of  communications  network.  Communication  via  some 
combination  of  the  above,  such  as  a  file  server  on  a  local  area  network,  is  also 
common  [Ref.  3].  In  the  Computer  Science  Department  at  the  Naval  Postgraduate 
School,  a  heterogeneous  mix  of  stand-alone  workstations,  file  server  supported 
workstation  clusters,  and  minicomputers  communicates  via  Ethernet. 

Programming  distributed  architectures  has  inspired  creativity.  The 
fundamental  problems  with  distributed  programming  are  the  communications  between 
processes  and  the  temporal  interaction  of  the  processes.  Communicating  sequential 
processes  [Ref.  14],  distributed  processes  [Ref.  15],  and  remote  procedure  calls 
[Refs.  2, 16]  have  all  been  proposed  as  primitives  to  hide  message  passing  from  the 
programmer.  Remote  procedure  calls  [Refs.  2, 3]  and  communicating  sequential 
processes  [Ref.  17]  have  been  implemented.  However,  even  today,  none  of  these  is 
generally  available  as  a  standard  mechanism  across  varied  architectures.  We  have 
created  simpler  (but  less  general)  communication  routines  for  use  among  heterogeneous, 
distributed,  standalone  computers. 


I 

Complex  projects  can  require  the  resources  of  more  than  one  computer. 
Graphics  portions  are  best  handled  by  the  specialized  hardware  of  a  graphics  workstation, 
such  as  a  Silicon  Graphics,  Inc.  IRIS.  Artificial  intelligence  portions  are  best  handled  by 
a  Lisp  machine,  such  as  a  Symbolics*  or  a  Texas  Instruments  Explorer**.  Database 
requests  can  be  made  to  a  machine  with  appropriate  database  software.  A  general 

i 

purpose  computer,  such  as  the  Digital  Equipment  Corporation  VAX***,  car.  be  used  for 
additional  processing  power,  file  storage,  or  other  administrative  support.  Providing  easy 
access  across  such  a  mix  of  heterogeneous  computers  is  a  large  task  [Ref.  3].  The  simple 
mechanism  described  in  this  work  gives  communication  access  between  cooperating 
processes  running  on  diverse  hardware.  It  leaves  temporal  design  to  the  application 
developer,  while  providing  the  tools  for  synchronous  and  asynchronous  interaction. 

3.  Communication 

Communications  between  computers  cooperating  on  a  task  can  be  one-to-one, 
many-to-one,  or  one-to-many.  It  can  be  synchronous  or  asynchronous.  Any,  or  all,  of 
these  can  be  required  for  one  visual  simulation. 

One-to-one,  or  direct  connect,  communications  puts  the  lowest  load  on  the 
network  when  there  are  few  messages  to  be  sent.  A  single  virtual  channel  between  the 
two  processes  is  required.  Each  communication  between  any  two  processes  comprises 
one  message.  All  messages  are  known  to  be  intended  for  the  receiving  process.  These 
messages  can  be  sent  synchronously  or  asynchronously.  Direct  connect  communication 
requires  one  action  by  the  sender  and  one  by  the  receiver.  With  more  processors. 


*  Symbolic*  is  a  trademark  of  Symbolic),  Incorporated. 

**  Explorer  ii  a  trademark  of  Texas  Instruments  Incorporated. 

***  VAX  is  a  registered  trademark  of  Digital  Equipment  Corporation 
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potential  virtual  channels  grow  in  number  geometrically.  For  a  fully  connected  network, 
the  virtual  channels  required  can  exceed  capacity.  The  potential  messages  required  also 
grow  geometrically  in  number. 

One-to-many,  or  broadcast,  communications  puts  the  lowest  load  on  the 
sending  process.  A  message  is  sent  to  all  other  processes  that  are  connected  to  it.  It 
requires  one  action  by  the  sender,  and  two  actions  by  each  receiver  (the  reception  and  a 
decision  on  whether  the  message  is  intended  for  that  receiver).  It  also  places  one  to  n 
messages  on  the  network  (depending  on  how  the  network  and  the  broadcast  protocols  are 
designed).  It  is  primarily  used  in  an  asynchronous  mode,  although  synchronous  protocols 
could  be  designed. 

Many-to-one  communications  puts  the  highest  load  on  the  receiving  process.  It 
requires  two  actions  by  the  receiver  on  every  message  that  is  sent  by  any  connected 
process.  It  is  also  a  primarily  asynchronous  method.  The  receiver  portion  of  a  process 
sees  many-to-one  whenever  broadcast  protocols  are  the  only  ones  used  in  a  visual 
simulation. 

C.  Organization 

The  previous  sections  of  this  chapter  provide  background  on  visual  simulation, 
distributed  architectures,  and  communication  paradigms.  Chapter  n  describes  the 
hardware  and  software  environment  in  the  Computer  Science  Department  at  the  Naval 
Postgraduate  School.  The  protocols  developed  are  discussed  in  Chapter  HI.  Chapter  IV 
describes  die  implementation  of  the  protocols.  Chapter  V  covers  the  use  of  these 
protocols.  The  performance  of  the  protocols  is  detailed  in  Chapter  VI.  Chapter  VII 
concludes  with  a  discussion  of  limitations,  future  extensions  and  research  topics,  and 
summarizes  the  research  conducted.  Listings  of  the  program  source  code  for  each  of  the 
hardware  systems  are  included  as  Appendices. 


n.  existing  System 


A.  INTRODUCTION 

The  distributed  architecture  available  in  the  Naval  Postgraduate  School  Computer 
Science  Department  Graphics  and  Video  Laboratory  is  Ethernet-connected  workstations 
and  minicomputers.  The  workstations  include  IRIS  2400,  3120,  and  4D  graphics, 
Symbolics  36xx*  and  TI  Explorer  Lisp,  ISI AI,  and  Sun-3s**.  The  minicomputers  include 
VAX  11/785  and  an  ISIV  minicomputer  complex  providing  database  services.  All 
computers,  except  the  Symbolics  and  TI,  use  some  version  of  UNIX***  as  the  primary 
operating  system. 

B.  HARDWARE 
1.  Network 

Ethernet  connects  all  the  computers  in  our  lab.  There  is  a  backbone  network 
and  subnetworks  for  certain  groups  of  computers.  Currently  there  are  two  subnetworks, 
one  for  the  ISIV  minicomputers  and  one  for  the  ISI  AI  workstations.  Subnetworks  are 
planned  for  the  IRIS  workstations,  the  Sun  Workstations****,  and  the  Symbolics  and  TI 
workstations.  Figure  2. 1  illustrates  the  network  configuration. 


*  Symbolic*  3600,  Symbolics  3640,  Symbolic*  3650,  and  Symbolics  3675  are  trademark*  of  Symbolic*,  Inc. 

**  Sun-3  ia  a  trademark  of  Sun  Microsystems,  Inc. 

UNIX  i«  a  trademark  of  AT&T  Bell  Laboratories 

****  Sun  Workstation  ia  a  registered  trademark  of  Sun  Microsystems,  Inc. 


All  computers  support  TCP/IP  protocols.  The  Symbolics  Lisp  machines  also 
use  the  CHAOS  protocol  to  provide  file  server  services  from  syml  to  the  other  Symbolics 
machines.  This  logical  local  area  network  (LAN)  uses  the  Ethernet  backbone  for  its 
messages.  The  Sun  file  servers  also  support  their  diskless  nodes  over  the  backbone 
Ethernet. 

2.  Workstations 

a.  Silicon  Graphics,  Inc.  IRIS 

Table  2.1  shows  the  IRIS  workstation  configurations.  All  are  connected 
directly  to  the  backbone  Ethernet.  The  proprietary  Geometry  Engines  in  each  of  these 
workstations  allows  three  dimensional  color  graphics  displays  to  be  generated  and 
updated  in  real-time.  The  primary  use  of  these  machines  is  for  color  graphics. 

b.  ISI AI 

Table  2.2  shows  the  ISI  AI  workstation  configurations.  Only  ai8  is 
connected  directly  to  the  backbone  Ethernet.  The  other  workstations  arc  connected  to  it 
in  a  subnetwork.  These  workstations  arc  used  primarily  for  artificial  intelligence 
projects.  The  ai8  machine  provides,  as  well  as  a  gateway  to  the  backbone  Ethernet,  file 
server  support  for  the  other  workstations.  Their  high  resolution  black  on  white  monitors, 
although  bitmapped,  have  rudimentary  graphics  capabilities. 


Table  2. 1  IRIS  WORKSTATION  CONFIGURATIONS 


Nickname 

Model 

No. 

Memory 

(MBytes) 

Disk 

Capacity 

Bit 

Planes 

Floating 

Point 

Accelerator 

Screen 

Resolution 

4D/70G 

8 

56 

N/A 

1280x1024 

2400  Turbo 

6 

32 

Y 

1024x768 

Hr*  ’ 

3120 

4 

144MB 

32 

N 

1024x768 

iris4 

4D/70G 

8 

380MB 

56 

N/A 

1280x1024 

Table  2.2  ISI AI  WORKSTATION  CONFIGURATIONS 


Nickname 

Model 

No. 

Memory 

(MBytes) 

Bit 

Planes 

Screen 

Resolution 

ail 

V8WS 

4 

101MB 

2 

1280x1024 

ai2 

V8WS 

4 

101MB 

2 

1280x1024 

ai3 

V8WS 

4 

101MB 

2 

1280x1024 

ai4 

V8WS 

4 

101MB 

2 

1280x1024 

ai5 

V8WS 

4 

101MB 

2 

1280x1024 

ai6 

V8WS 

4 

101MB 

2 

1280x1024 

ai7 

V8WS 

4 

101MB 

2 

1280x1024 

ai8 

V16WS 

4 

403MB 

2 

1280x1024 

c.  Sun-3/50 

Table  2.3  shows  the  Sun  Workstation  configurations.  All  are  connected 
directly  to  the  backbone  Ethernet.  The  black-on-white  monitors  of  the  Sun  diskless 
workstations  are  primarily  used  for  administrative  tasks  at  this  time. 

d.  Symbolics  36xx 

Table  2.4  shows  the  Symbolics  workstation  configurations.  All  are 
connected  directly  to  the  backbone  Ethernet.  The  Symb  dies  workstations  are  used  for  a 


Table  2.3  SUN  WORKSTATION  CONFIGURATIONS 


Nickname 

Model 

No. 

Memory 

(MBytes) 

Disk 

Capacity 

Bit 

Planes 

Screen 

Resolution 

sunsl 

BQQI 

12 

490MB 

2 

1280x1024 

sunlO 

■11 

4 

N/A 

2 

1280x1024 

sunli 

3/50 

4 

N/A 

2 

1280x1024 

sunl2 

3/110 

4 

N/A 

2 

1280x1024 

sunl3 

3/110 

4 

N/A 

2 

1280x1024 

sunl4 

3/60 

4 

N/A 

2 

1280x1024 

sun  15 

3/60 

4 

N/A 

2 

1280x1024 

sunl6 

3/60LC 

4 

N/A 

10 

1280x1024 

sunl7 

3/50 

4 

N/A 

2 

1280x1024 

sunl8 

3/50 

4 

N/A 

2 

1280x1024 

sunl9 

3/50 

4 

N/A 

2 

1280x1024 

suns2 

3/1 80S 

12 

490MB 

2 

1280x1024 

sun20 

3/60LC 

4 

N/A 

10 

1280x1024 

sun21 

3/60LC 

4 

N/A 

10 

1280x1024 

i 


Table  2.4  SYMBOLICS  WORKSTATION  CONFIGURATIONS 


Nickname 

Model 

No. 

IKSESSI 

Bit 

Planes 

Color 

Screen 

Resolution 

■aw 

3675 

5 

1GB 

24 

Y 

1280x1024 

3640 

1 

180MB 

1 

N 

1280x1024 

3640 

1 

180MB 

8 

Y 

1024x1024 

3650 

5 

512MB 

1 

N 

1280x1024 

variety  of  research  projects  involving  artificial  intelligence.  The  syml  machine  provides 
file  server  support  for  the  other  Symbolics  machines  using  the  Chaos  protocol  and  its  one 
GigaByte  (unformatted)  storage  capacity.  The  color-capable  systems  are  used  to  display 
static  information  with  color  providing  an  easier  human  interface, 
e.  Texas  Instruments  Explorer 

Table  2.5  shows  the  Explorer  workstation  configurations.  All  are 
connected  directly  to  the  backbone  Ethernet.  The  TT  Explorers  are  also  used  for  artificial 
intelligence  projects.  They  have  the  least  graphical  capabilities  of  any  of  the 
workstations. 

3.  Digital  Equipment  Corporation  VAX  1 1/785 

Table  2.6  shows  the  two  DEC*  VAX  1 1/785  computer  configurations.  Both  are 
connected  directly  to  the  backbone  Ethernet.  Only  the  unixl  machine  was  included  in 
this  project.  The  vmsl  machine  may  not  be  available  in  the  future,  so  the  effort  to 


Table  2.5  EXPLORER  WORKSTATION  CONFIGURATIONS 


Nickname 

Model 

No. 

1  . 

KE&zSSI 

| 

Bit 

Planes 

Screen 

Resolution 

— 

I 

4 

280MB 

1 

1024x808 

WBm 

I 

8 

420MB 

1 

1024x808 

I 

8 

420MB 

1 

1024x808 

WSSm 

I 

2 

140MB 

1 

1024x808 

*  DEC  if  ■  regiftered  trademark  of  Digital  Equipment  Corporation 


Table  2.6  VAX  CONFIGURATIONS 


Nickname 

Model 

No. 

Memory 

(MBytes) 

Disk 

Capacity 

Operating 

System 

unixl 

■ 

24 

1395MB 

UNIX 

vmsl 

wrfTiTm 

8 

1442MB 

VMS 

develop  appropriate  code  was  deemed  unnecessary.  The  unixl  machine  is  nps-cs.arpa 
on  MILNET  and  is  the  sole  external  access  point  to  other  machines  connected  locally  via 
Ethernet.  It  supports  the  various  dial-up  lines,  as  well  as  other  administrative  functions. 

4.  ISIV  minicomputers 

The  computers  in  Table  2.7  make  up  the  ISIV  minicomputer  complex.  Only 
isiv8  is  connected  to  the  backbone  Ethernet.  The  other  machines  are  connected  to  isiv8 
in  an  Ethernet  subnetwork.  The  ISIV  minicomputers  provide  a  high  performance,  multi¬ 
backend  distributed  database.  Any  of  the  high-resolution  black  on  white  monitors  can  be 
used  with  any  of  the  hosts  on  the  subnetwork.  The  character  displays  can  also  be  used  on 
any  of  the  subnetwork  hosts.  The  graphics  capabilities  of  these  machines  are  limited. 


Table  2.7  ISIV  DATABASE  MACHINE  CONFIGURATION 


Nickname 

Model 

No. 

Memory 

(MBytes) 

Disk 

Capacity 

Bit 

Planes 

Screen 

Resolution 

isivl 

V24S 

4 

602MB 

N/A 

80x24char 

isiv2 

V24WS 

4 

500MB 

2 

1280x1024 

isiv3 

V24WS 

4 

602MB 

2 

1280x1024 

isiv4 

V24WS 

4 

500MB 

2 

1280x1024 

isiv5 

V24S 

4 

602MB 

N/A 

80x24char 

isiv6 

V24S 

4 

602MB 

N/A 

80x24char 

isiv7 

V24WS 

4 

602MB 

2 

1280x1024 

isiv8 

V24WS 

4 

459MB 

2 

1280x1024 

isiv9 

V24S 

4 

602MB 

N/A 

80x24char 

C.  Software 

1.  UNIX  Machines 

Two  versions  of  UNIX  are  commonly  used.  The  machines  purporting  to  use 
System  V*,  also  incorporate  characteristics  of  4.2BSD  and  4.3BSD.  The  relevant 
incorporation  is  the  Berkeley  socket  mechanism. 

a.  4.3BSD 

A  "pure"  4.3BSD  system  (4.3  BSD  UNIX  #11)  exists  only  on  unixl.  The 
ISIV  minicomputers  use  4.2  BSD  UNIX  Release  3.07,  with  a  multi-backend  database 
system  installed  [Refs.  18-20J.  The  ISI  AI  workstations  use  IS68K  4.3  BSD  UNIX:  4.0D 

#2. 

b.  System  V 

The  IRIS  4D  systems  use  UNIX  System  V-based  version  4D1-2.2.  The 
IRIS  2400  and  3120  systems  use  UNIX  System  V-based  version  GL2-W3.6.  Both  have 
extensive  4.3BSD  extensions.  The  Sun-3  uses  an  almost  System  V  version  of  4.2BSD 
UNIX.  The  currently  installed  release  is  3.4. 

2.  Lisp  Machines 

a.  Genera 

The  Symbolics  Lisp  Machines  first  used  Genera  6.0  software.  All 
machines  are  now  on  Genera  7. 1 . 

b.  Explorer 

The  TI  Explorer  lisp  machine  first  used  Explorer  version  1.0.2  software. 
All  machines  are  now  on  version  3.4  except  expl ,  which  is  still  on  version  3.2. 


*  UNIX  System  V  is  a  trademarlc  of  AT&T  Bell  Laboratories 
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D.  SUMMARY 


The  configuration  described  above  is  constantly  changing.  Additional  machines  are 
acquired.  Older  machines  receive  hardware  upgrades.  The  network  is  reconfigured. 
Software  releases  are  updated  (especially  4.2BSD  UNIX  to  4.3BSD  UNIX).  The 
fundamental  needs  for  distributed  computation  in  this  heterogeneous  environment 
remain. 


reception.  While  the  conversion  is  unnecessary  when  communicating  between  similar 
architectures,  it  greatly  simplifies  the  task  of  communicating  between  fundamentally 
different  architectures.  Knowledge  of  the  other  machine’s  architecture  is  not  required. 
The  inherent  portability  of  this  solution  outweighs  the  processing  cost. 

A  message  is  created  with  three  fields.  The  type  field  is  a  one-character  field. 
It  contains  the  appropriate  code  from  Table  3.1.  The  length  field  is  a  four-character  field. 
It  contains  an  ASCII  string  from  0001  to  9999.  This  string  gives  the  length  of  the  data 
field.  The  data  field  is  a  variable  length  field  containing  the  ASCII  representation  of  the 
data  element.  Figure  3.1  illustrates  these  fields. 

While  C  programmers  are  continuously  concerned  with  data  types,  Lisp 
programmers  are  not.  The  Lisp  routines  support  arrays  of  characters,  single  integers,  and 
single  floating  point  numbers.  Each  of  these  is  an  object.  Objects,  not  types  (as  implied 
in  Table  3.1),  are  received  and  sent  by  lisp  applications.  The  underlying  protocol  is  the 
same,  the  application  interface  is  different3. 


Position 


1 

2  3  4  5 

6  7  ...  n 

T 

y 

p 

Length 

Data 

e 

Figure  3.1  Message  Format 


3  Chapter  5  discusses  applications'  use. 


Full-duplex  stream  sockets  are  used  to  provide  sequenced,  reliable  connection 
between  machines.  The  sockets  are  created  in  the  DARPA  Internet4  domain.  The 
Internet  pseudo-protocol  is  used  [Ref.  22].  No  out-of-band  capability  was  included.  We 
could  not  envision  a  use  for  it,  since  our  protocol  is  inherently  asynchronous.  If  a  strictly 
synchronous  protocol  was  used,  out-of-band  transmission  might  be  necessary  to  interrupt 
for  an  urgent  message.  In  an  asynchronous  protocol,  however,  encoding  the  next 
message  gives  the  same  effect.  Processing  overhead  for  encoding  is  no  greater  than  for 
continuous  monitoring  for  an  out-of-band  message.  With  only  a  small  volume  of  data 
transfers  expected,  no  urgent  message  waits  very  long. 

Two  ports,  each  with  its  own  stream  socket,  are  used  for  each  channel  between 
machines.  Although  full-duplex,  the  stream  sockets  are  used  in  a  simplex  mode.  The 
separate  sockets  are  used  because  two  processes  cannot  be  bound  to  the  same  socket  at 
the  same  time.  Two  separate  UNIX  processes  then  monitor  the  independent  send  and 
receive  sockets.  Blocking  sockets  are  used,  avoiding  processing  overhead  for  busy¬ 
waiting.  While  non-blocking  sockets  are  available  in  4.3BSD  [Ref.  21:  p.  25],  they  were 
not  explicitly  available  in  4.2BSD  [Ref.  22],  Operating  systems  might  include  4.2BSD 
sockets  rather  than  4.3BSD  versions  and  so  the  blocking  socket  mechanism  was  deemed 
more  portable.  Both  TCP/IP  and  the  C  routines  provide  buffering. 

On  the  TI  Explorer,  sockets  were  also  blocking5.  Direct  access  was  made  to 
the  TCP  methods  provided.  Lisp  streams  are  used  for  the  Symbolics  lisp  routines.  The 

*  This  is  the  underlying  mechanism  of  the  Defense  Data  Network  (DDN)  and  was  chosen  for  its  wide  availability 
and  applicability  to  Department  of  Defense  problems. 

5  Version  1 .0  of  the  Explorer  TCP/IP  software  uses  blocking  sockets  Version  2.0  uses  non-blocking  sockets. 
There  has  been  no  update  of  this  system’s  TI  Explorer  lisp  routines  to  version  2.0. 


lisp  stream  mechanism  isolates  the  code  from  the  issues  revolving  around  blocking 
versus  non-blocking  sockets. 


C.  BROADCAST 

A  broadcast  message  is  sent  to  all  machines  on  a  local  Ethernet.  Those  machines 
that  are  waiting  for  some  broadcast  message  will  probably6  receive  it.  If  a  machine  on  a 
subnetwork  is  to  get  a  broadcast  message,  an  application  must  run  on  the  gateway 
machine  that  will  rebroadcast  on  the  subnetwork  any  messages  received  on  the  backbone 
Ethernet.  Machines  not  expecting  a  broadcast  message  must  nevertheless  process  it  and 
reject  it  as  inappropriate.  The  extra  load  on  all  machines  connected  to  the  Ethernet 
restricts  broadcasting  to  infrequent  occurences  until  most  of  the  machines  used  in 
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simulations  are  on  a  private  subnetwork. 

1.  High-Level  Protocol 

We  expect  users  of  the  broadcast  protocol  to  mix  its  use  with  the  use  of  direct 
connections.  The  same  data  types  and  messages  are  supported  (see  Table  3.1). 

2.  Supporting  Protocols 

Full-duplex  datagram  sockets  are  used  to  provide  connectionless  broadcast 
capability.  The  sockets  are  created  in  the  DARPA  Internet  domain.  As  with  our  use  of 
stream  sockets  for  the  direct  connection  protocol,  we  use  these  full-duplex  datagram 
sockets  in  a  simplex  mode.  We  use  a  sending  socket  for  one-way  sending  of  a  broadcast 
message  to  all  other  machines  on  a  single  network  or  subnetwork.  We  use  a  receiving 
socket  for  one-way  receiving  from  a  specific  broadcasting  machine  on  the  network  or 


6  Unlike  the  direct  connect  protocol,  the  broadcast  protocol  does  NOT  guarantee  reception.  Trying  to  provide 
such  a  guarantee  requires  a  feedback  machanism  so  that  the  sender  knows  that  the  machines  expected  to  receive  the 
broadcast  did  so.  This  is  difficult  without  resorting  to  a  direct  connection  or  flooding  the  network  with  messages. 


7  The  IRIS  machines  and  the  Lisp  machines  are  the  ones  principally  used  for  visual  simulation. 


subnetwork.  Direct  connection,  with  its  use  of  guaranteed  reliable  stream  sockets,  is 
used  for  any  other  communication,  including  return  messages.  [Ref.  21:  pp.  32-34] 

As  in  the  direct  connection  protocol,  independent  UNIX  processes  are  bound  to 
the  sockets.  Since  broadcasting  is  a  one-way  activity,  a  sender  or  receiver  only  spawns 

one8  UNIX  process. 

D.  Summary 

By  building  our  high-level  protocols  on  top  of  DARPA  TCP/IP  standards,  we  provide 
the  highest  degree  of  portability  possible  today.  By  using  full-duplex  stream  sockets  and 
datagram  sockets  in  a  simplex  mode,  we  do  not  make  full  utilization  of  a  socket’s 
capabilities.  However,  this  concern  is  outweighed  by  the  increased  simplicity  and 
resultant  maintainability  of  the  code.  The  use  of  ASCII  character  strings  for  the  messages 
is  simple  and  makes  interconnection  with  diverse  architectures  straightforward. 


1  If  broadcasting  were  used  exclusively  for  complete  connectivity,  each  of  n  machines  would  spawn  n  processes. 
If  direct  connection  was  used  exclusively  for  complete  connectivity,  each  of  n  machines  would  spawn  2n-2  processes. 


IV.  IMPLEMENTATIONS 


A.  Introduction 

The  first  connection  was  between  the  IRIS  2400-Turbo  and  TI  Explorer.  Then  the 
Symbolics  Lisp  machines  were  included.  These  routines  have  had  extensive  use 
[Refs.  8, 9, 11].  The  IRIS  functions  were  updated  for  the  IRIS  4D,  coincidentally 
providing  Mex  support  on  the  older  IRIS  machines.  Broadcast  capability  was  added  for 
UNIX-based  machines.  A  port  to  4.3BSD  UNIX  (application  calls  unchanged)  was  begun. 

B.  System  V  Unix 

All  our  System  V  UNIX-based  systems  include  the  socket  mechanism  first 
introduced  by  4.2BSD.  Sockets  are  a  key  aspect  of  all  implementations.  We  expect  they 
will  become  part  of  System  V  or  its  successors  [Ref.  23].  The  System  V-unique 
semaphore  and  shared  memory  interprocess  communication  (IPC)  capabilities  are  also 
used. 

1.  Silicon  Graphics.  Inc.  IRIS  2400 
a.  Sockets 

The  socket  was  introduced  in  4.2BSD  as  the  preferred  metaphor  for  IPC.  It 
was  easy  and  efficient  to  implement  and  the  select  mechanism  could  be  used  to 
implement  remote  procedure  calls,  if  desired  [Ref.  23].  System  V  had  no  comparable 
mechanism  until  version  3  was  released  with  streams.  The  BSD  sockets  were  included 
by  many  vendors,  Silicon  Graphics,  Inc.  included9.  While  the  use  of  sockets  could  be 


9  The  System  V  version  available  on  the  IRIS  machines,  at  the  start  of  the  project,  was  version  2  and  so  streams 
were  not  considered. 


replaced  with  streams,  device  drivers  would  have  to  be  written.  The  advantage  of 
streams  is  the  ability  to  filter  them  between  streamhead  and  the  actual  device  driver. 
These  filters,  however,  reside  in  the  kernel’s  address  space  and  have  the  kernel’s 
permissions  [Ref.  24],  In  our  environment,  the  potential  performance  increase  is  not  as 
important  as  the  requirement  for  simplicity. 

The  system  call  for  socket  creation  is  socket.  The  system  calls  supporting 
socket  configuration  are  setsockopt ,  bind ,  connect,  and  accept 10  [Ref.  22],  To  simplify 
their  use,  these  are  all  repackaged  into  four  high  level  routines:  connectserver  and 
connect  client  for  direct  connection,  start  broadcast  and  broadcast  receive  for 
broadcast.  These  routines  are  encapsulated  in  netV.c.  netV.c  can  be  separately  linked 
with  any  application  that  needs  to  make  a  server/client  connection  using  stream  sockets 
or  a  broadcasting  connection  using  datagram  sockets.  Table  4.1  describes  the  four 
routines. 

Using  the  socket  number 11 ,  a  process  can  transmit  data  through  the  socket. 
In  our  system,  sockets  for  inter-computer  communication  are  created  and  used  by  the 
send  and  receive  processes  exclusively.  The  file  netV.c  is  not  linked  with  the  application 
at  all. 


10  The  accept  system  call  is  only  relevant  to  stream  sockets.  The  setsockopt,  bind,  and  connect  system  calls  are 
used  with  both  stream  sockets  and  datagiam  sockets. 

11  In  the  direct  connect  protocol,  the  server  process  reads  from  and  writes  to  n  remote  socket  number.  The  client 
process  reads  from  and  writes  to  its  local  socket  number.  The  reason  for  this  is  that  a  server  could  be  connected  to  dif¬ 
ferent  clients  (although  not  in  our  implementation)  at  different  times.  The  client,  meanwhile,  is  only  going  to  connect 
to  the  one  server.  In  the  Internet  domain,  all  necessary  muting  information,  for  either  server  or  client,  is  contained  in  a 
sockaddr  in  structure  and  is  accessed  (transparently)  via  the  socket  number 

In  the  broadcast  protocol,  both  the  broadcaster  and  recei verts)  use  their  fiscal  socket  number  beenuse  they  are 
using  connectionless  datagram  sockets.  The  routing  information  is  also  contained  in  a  sockaddr  in  structure. 


Table  4. 1  SOCKET  SUPPORT  FUNCTIONS 


Function 

Description 

Use 

connect_server 

Creates  socket.  Binds  that 
socket  to  remote  client  ad¬ 
dress  and  port.  Waits  to  ac¬ 
cept  the  remote  client  con¬ 
nection.  Returns  the  socket 
number  for  the  remote  client. 

int  connect_serverf  rcmote  client  name,  port_number  ) 
char  remote_client  jiameQ; 
int  poit_number, 

remote_socket  ■  connectaerverf  remote_client_name, 

port_number ) 

connect_client 

Creates  socket.  Binds  that 
socket  to  remote  server  ad¬ 
dress  and  port.  Connects 
with  remote  server.  Returns 
the  local  socket  number. 

int  connect_client(  remote_server_name,  poit  number  ) 
char  remote_servei_name(J; 
int  port_number, 

local_socket  =  connect_client(  remote_eerver_name, 

port_number ) 

start_broadcast 

Creates  socket.  Sets  it  to 
broadcast  mode.  Binds  it  to 
local  address  and  specified 
local  port.  Returns  the  local 
socket  number. 

int  start_broadcast(  port_number  ) 
int  port_number, 

localsocket  >=  start_broadcast(  port_number  ) 

broadcastjreceive 

Creates  socket.  Binds  it  to 
local  address  and  specified 
port.  Adds  broadcaster  ad¬ 
dress  and  port.  Returns  the 
local  socket  number. 

int  broadcast_receive(  broadcaster_name,  broadcaster j>ort ) 
char  broadcaster_name[]; 
int  broadcaster_port; 

local  socket  =  broadcast_receive(  broadcaster_name, 

broadcaster jport  ) 

b.  Semaphores 

The  semaphore  mechanism  was  chosen  as  the  least  expensive,  in  both 
space  and  time,  for  communication  between  processes.  Signals  could  have  been  used, 
but  implementation  would  have  been  more  complex  and  less  reliable.  Signal-based 
communication  functions  would  also  have  been  more  difficult  for  the  application 
programmer  to  use  [Ref.  25:  p.  10].  There  are  two  semaphore  ids  maintained  for  each 
connection12.  One  is  used  to  communicate  with  the  send  process;  one  is  used  to 
communicate  with  the  receive  process.  The  two  semaphores  are  both  used  to  signal  their 
process  when  it  is  safe  to  proceed.  A  send  process  is  permitted  to  proceed  only  after  the 


,J  Two  semaphore  ids  are  required  for  direct  connect  protocol  connections  since  both  a  send  and  a  receive  pro¬ 
cess  are  spawned.  Two  semaphore  ids  are  still  created  for  broadcast  protocol  connections,  even  though  only  one  pro¬ 
cess  is  spawned. 
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application  has  requested  a  write  action  on  the  channel.  A  receive  process  is  permitted 
to  proceed  only  after  the  application  has  read  all  data  from  the  shared  memory  buffer. 
Neither  the  send  nor  the  receive  process  is  executing  more  than  absolutely  necessary, 
assuring  maximum  availability  of  the  local  processor  to  the  application. 

The  system  calls  supporting  semaphores  are  semget,  semop,  and  semctl. 
To  simplify  their  use,  they  are  repackaged  into  three  high  level  routines:  semtran,  P,  and 
V  [Ref.  25:  pp.  188-190].  These  routines  (and  a  support  routine  semcall )  are 
encapsulated  in  semaphores.  It  can  be  separately  linked  with  any  application  that  needs 
semaphores.  Table  4.2  describes  the  three  routines, 
c.  Shared  Memory 

A  cost  barrier  to  IPC  in  UNIX  is  the  cost  of  copying  data  from  one  process 
to  the  kernel  and  then  from  the  kernel  to  another  process.  Using  a  shared  memory 
segment,  as  a  buffer,  minimizes  this  overhead.  To  further  reduce  overhead  from  system 
calls,  only  a  single  segment  is  created.  An  application  accesses  the  entire  segment,  while 
a  send  or  receive  process  accesses  only  its  preassigned  section.  Figure  4.1  displays  the 
layout.  The  message  area  of  each  section  is  used  for  several  purposes.  It  is  formatted  as 

Table  4.2  SEMAPHORE  SUPPORT  FUNCTIONS 


Function 

Description 

Use 

semtran 

Creates  a  semaphore  associ¬ 
ated  with  a  key.  Returns  a 
semaphore  id. 

int  semtran(  key  ) 
int  key; 

sid  =  semtran(  key  ); 

P 

Acquire  semaphore 

void  P(  sid ) 
int  sid; 

V 

Release  semaphore 

-  - 

void  V(  sid ) 
int  sid; 

13  The  data  must  also  be  valid  in  the  shared  memory  buffer.  All  this  is  transparent  to  the  application,  which  only 
issues  a  write  command. 


a  long  (4-byte)  integer.  Table  4.3  describes  the  meaning  of  three-state  values  placed  in 
this  area. 


Table  4.3  SHARED  MEMORY  MESSAGES 


Value 

Meaning 

to 

send 

Meaning 

to 

receive 

Meaning 

to 

Application 

positive 

Data  of  length  given  ii 
in  shared  memory, 
ready  to  be  sent. 

Application  has  not 
finished  reading  data 
from  shared  memory. 

send'.  Data  in  shared  memory 
has  not  yet  been  sent  to  other 
machine. 

receive:  Valid  data  of  length 
given  is  in  shared  memory, 
ready  to  be  read. 

zero 

Nothing  ready  to  be 
sent. 

Application  has  read 
data  from  shared 

memory,  Message 

front  other  machine  can 
be  read,  up  to  LAR- 
GES TREAD  bytes. 

send:  Previous  message  has 
been  sent.  Ready  to  send 
next  message. 

receive:  No  valid  data  in 
shared  memory. 

BOSSES 

N/A 

25 


The  system  calls  supporting  shared  memory  are  shmget,  shmat,  shmdt,  and 
shmctl  [Ref.  25:  pp.  192-198].  To  simplify  their  use,  they  are  repackaged  into  four  high 
level  routines:  sharedsegment,  dynamicsharedsegment,  detachsharedsegment,  and 
deletesharedsegment.  These  routines  (and  a  support  routine  attach  within  datasegment) 
are  encapsulated  in  shareseg.c.  It  can  be  separately  linked  with  any  application  that 
needs  shared  memory.  Table  4.4  describes  the  four  routines. 


The  implementation  of  shared  memory  on  the  IRIS  2400  and  IRIS  3120 
was  a  surprise.  A  basic  UNIX  memory  allocation  scheme  is  shown  in  Figure  4.2.  Each 
process  has  its  own  text,  data,  and  stack  sections.  Neither  the  relative  locations  of  these 
sections  nor  the  direction  of  growth  for  stack  and  data  sections  is  specified  for  UNIX. 
The  shared  memory  segments  are  logically  part  of  the  data  section  [Ref.  26:  p.  151]. 


Table  4.4  SHARED  MEMORY  SUPPORT  FUNCTIONS 


Function 

Description 

Use 

sharedsegment 

Creates  (if  not  already  in  ex¬ 
istence)  a  shared  memoiy 
segment  associated  with  a 
key.  Attaches  application  to 
that  shared  memory  segment. 
Returns  a  shared  memory 
segment  address  and  id. 
Does  not  permit  subsequent 
dynamic  memory  allocation. 

char  *  share  dec  gmentt  key,  nbytes,  shmid  ) 
long  key, 
long  nbytes; 
int  ‘shmid; 

segment  =  sharedsegment!  key,  nbytes,  shmid ) 

dynamicsharedsegment 

Creates  (if  not  already  in  ex¬ 
istence)  a  shared  memory 
segment  associated  rith  a 
key.  Attaches  application  to 
that  shared  memory  segment. 
Returns  a  shared  memory 
segment  address  and  id.  Per¬ 
mits  subsequent  dynamic 
memory  allocation. 

char  ‘dynamicsharedsegment!  nummachines, 
key,  nbytes,  shmid,  free  space  ) 
int  nummachines; 
long  key; 
long  nbytes; 
int  *shmid; 
int  free  space; 

segment  =  dynamicsharedsegment!  num¬ 

machines,  key,  nbytes,  shmid.  free  space  ) 

detachsharedsegment 

Detach  shared  memory  seg¬ 
ment  from  application 

void  detachsharedsegment!  segment  ) 
char  ‘segment; 

deletesharedsegment 

Delete  shared  memory  seg¬ 
ment 

void  deletesharedsegment  segment,  shmid  ) 
char  ‘segment; 
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Figure  4.2  UNIX  Memory  Allocation 


Actual  implementation  is  left  to  the  team  porting  UNIX  to  the  machine.  The  Silicon 
Graphics,  Inc.  implementation  attaches  a  shared  memory  segment  to  the  first  available 
valid14  address  within  the  data  section.  However,  the  beginning  of  shared  memory 
delimits  the  size  of  all  other  sections  [Ref.  26:  pp.  367-370].  Figure  4.3  illustrates  this 


14  Shared  memory  segments  must  begin  on  a  page  boundary.  This  allows  easy  table-driven  access  by  multiple 
processes.  On  the  IRIS  2400  and  3120  machines,  the  Motorola  68000  architecture  is  used.  The  pages  tie  8 KBytes. 
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relationship.  While  no  dynamic  memory  calls15  are  made,  the  default  arrangement  works 
fine.  But  when  dynamic  memory  allocation — linked  lists  and  makeobjO  calls  are 
examples — is  needed,  the  technique  fails. 

To  allow  dynamic  memory  allocation,  the  shared  memory  segment  must 
be  attached  at  an  address  beyond  the  greatest  ever  required  for  regular  data.  Dynamic 
allocation  can  then  occur  without  reaching  the  shared  memory  segment.  Attaching  at  an 
unknown  address  >oth  within  the  data  section  and  sufficiently  beyond  existing  data  to 
permit  dynamic  data  section  growth,  can  be  done  at  least  two  ways.  First,  the  data 
section  can  be  expanded  until  it  is  as  large  as  possible,  then  the  shared  memory  segment 

15  Dynamic  memory  allocation  is  made  with  system  call  brk  or  alternate  sbrk.  Library  functions  malloc,  realloc, 
and  calloc  use  brk  and  so  also  do  dynamic  memory  allocation. 


can  be  attached  at  a  valid  location  just  inside  this  maximum  value.  While  minimizing 
application  programmer  effort,  this  technique  requires  many  system  calls  to  grow  the 
data  section.  It  also  has  the  fatal  flaw  of  limiting  the  stack  section,  if  the  stack  section 
and  data  section  grow  into  the  same  unallocated  memory.  Second,  the  application  can  be 
required  to  prespecify  the  maximum  amount  of  dynamic  memory  allocation  it  might  use. 

The  solution  adopted  is  adding  a  freespace  parameter  to  the 
sharedsegment  function;  and  renaming  it  the  dynamicsharedsegment  function.  The 
sharedsegment  function  was  retained  for  backward  compatibility.  The  freespace 
parameter  gives  the  caller  the  ability  to  specify  the  maximum  additional  memory 
required  for  the  application.  A  request  for  this  additional  space  is  made  before  the  shared 
memory  segment  is  attached.  After  acquiring  (and  freeing)  the  additional  space,  the  next 
available  address  is  determined  and  the  shared  memory  segment  is  attached  to  the  next 
valid  address.  We  have  now  established  the  shared  memory  segment  beyond  the 
specified  growth  of  the  application’s  data. 

When  multiple  machines  arc  connected  together,  there  must  be  a  separate 
shared  memory  buffer  for  each  channel.  There  is  no  way  to  connect  a  second  shared 
memory  segment.  The  solution  adopted  is  adding  a  nummachines  parameter  to  the 
dynamicsharedsegment  function.  The  nummachines  parameter  requires  the  application 
developer  to  specify,  in  advance,  the  maximum  number  of  channels  that  can  be  created  in 
the  application.  The  first  dynamicsharedsegment  call  establishes  a  shared  memory 
segment  big  enough  for  nummachines  maximum  requested  channels.  Subsequent 
dynamicsharedsegment  calls  return  the  same  shared  memory  id  as  the  first;  but  return  a 
different  address  within  the  segment.  Since  the  application  does  not  directly  access  these 
functions,  there  were  no  problems  caused  by  this  parameter  list  change. 


The  shared  memory  functions  are  isolated  from  the  application  by  the 
machinepath,  dynamicmachinepath,  dynamicmachinepaths,  and  deletemachinepath 
functions16.  For  the  direct  connect  protocol,  each  machinepath,  dynamicmachinepath,  or 
dynamicmachinepaths  call  spawns  both  a  send  and  a  receive  process.  For  the  broadcast 
protocol,  these  calls  spawn  only  a  send  process  (for  the  broadcaster)  or  a  receive  process 
(for  the  receiver).  In  all  cases,  the  spawned  processes  issue  a  sharedsegment  call  to 
attach  to  the  shared  segment  earlier  created  by  the  spawning  function.  A  command  line 
parameter  is  passed  providing  the  offset  into  the  shared  memory  segment  that  the 
spawned  process  is  to  use.  Figure  4.4  illustrates  a  system  with  three  machines  and  two 
channels. 

d.  Buffering 

(1)  Direct  Connect.  When  a  receive  process  is  quiescent,  waiting  for 
the  application  to  read  from  the  shared  memory  buffer,  anything  sent  to  it  is  buffered  by 
TCP/IF.  The  buffering  provides  the  reliable  delivery  promised  by  a  stream  socket.  The 
next  read  command  will  deliver  up  to  LARGESTREAD  bytes  into  the  receive  data  area  of 
the  shared  memory  buffer.  Since  the  messages  are  variable  length,  there  cannot  be  a 
guarantee  that  only  one  message  was  read17.  Multiple  messages  might  be  in  the  shared 
memory  buffer.  A  partial  message  might  be  in  the  last  bytes. 

The  shared  memory  buffer  management  is  handled  by  the  various 
read  functions18  provided.  Each  read,  requested  by  the  application,  is  satisfied  from  the 


14  See  Chapter  3.  Sections  A.l.b(l)  and  A.l.b(3)  for  more  information  on  these  functions. 

17  The  idea  to  pad  all  messages  to  some  arbitrary  size  was  considered  and  rejected.  Whatever  size  was  chosen 
would  always  be  too  small  for  some  character  array.  If  the  maximum  Ethernet  packet  size  was  chosen,  an  unnecessary 
network  dependence  would  be  introduced.  The  cost  of  application  buffer  management  is  considered  acceptable,  espe¬ 
cially  since  it  is  incurred  only  on  reads. 

'*  See  Chapter  5,  Section  A.l.b(2)  for  more  information  on  these  functions 
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shared  memory  buffer.  Remaining  valid  data  is  shifted  into  the  low  order  positions  of  the 
data  area.  The  count  of  valid  bytes,  held  in  the  message  area,  is  decremented.  The 
shared  memory  buffer  now  appears  as  it  would  have,  if  it  had  only  received  the 
remaining  data  and  not  the  first  message  at  all.  As  long  as  only  entire  messages  are 
received  (one  or  more  at  a  time),  this  works  well.  When  the  TCP/IP  buffer  has  more  data 
than  the  data  area  can  take  at  one  time,  however,  the  receive  process  deposits 
LARGESTREAD  bytes  in  the  shared  memory  data  area.  It  is  highly  unlikely  that  this  will 
be  on  a  message  boundary. 

A  socket  read  overwrites  all  data  in  the  data  area.  A  partial  data 
reception  must  be  stored  and  concatenated  with  bytes  from  the  next  socket  read  to  get  a 
complete  message.  The  protocol  area  was  introduced  to  retain  the  protocol 
information19  required  to  decipher  the  variable  length  messages.  The  count  of  already 
received  bytes  of  a  message  is  held  here  between  socket  reads.  A  message’s  protocol 
information  is  stored  here,  too.  Protocol  information  is  built  up  until  complete  (covering 
the  possibility  that  the  break  is  in  the  protocol  information  itself).  It  is  then  maintained 
until  the  entire  message  is  received  and  read  by  the  application.  The  buffering  works 
with  data  areas  as  small  as  four  bytes20. 

(2)  Broadcast.  The  datagram  socket  used  by  the  broadcast  protocol 
preserves  message  boundaries.  Each  recvfrom  call  to  a  socket  returns  only  one  message. 
This  message  must  be  no  longer  than  LARGESTREAD  bytes.  The  shared  memory  buffer 
management  routines  are  not  needed. 


19  See  Chapter  3,  Section  B.  1  for  a  deacription  of  the  protocol 

20  LARGESTREAD  must  be  specified  in  multiples  of  four  bytes.  The  smallest  possible  data  area  is  therefore 
four  bytes. 
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TCP/IP  keeps  unread  messages  on  a  queue.  This  queue  may  not  be  in 
sending  sequence.  If  the  queue  buffer  becomes  full,  subsequent  messages  are  lost 
[Ref.  21:  p.  8-8].  The  sending  buffer  can  easily  be  filled  if  many  messages  are  broadcast 
in  a  short  period  of  time.  Each  broadcast  message  must  be  processed  by  every  host  on 
the  Ethernet.  Only  then  can  the  next  be  sent.  No  access  for  manipulation  of  the  TCP/IP 
sending  buffer  is  provided  because  its  size  is  normally  specified  during  system  generation 
and  is  not  easily  manipulated  by  an  application  program. 

2.  Silicon  Graphics.  Inc.  IRIS  3120 

There  are  no  required  changes  to  the  IRIS  2400-Turbo  code.  The  Makefile 
must  be  changed  to  remove  the  -Zf  compile  flag,  since  there  is  no  floating  point 
accelerator  board  in  this  machine. 

3.  Silicon  Graphics.  Inc.  IRIS  4D 

The  IRIS  4D  required  programming  changes  only  to  the  shared  memory 
module,  shareseg.c.  The  path  name  for  user  directories  is  also  different.  Changes  were 
necessary  to  the  Makefile  because  the  lusrl include  directory  structure  changed. 


The  IRIS  4D  is  based  on  the  MIPS  RISC  architecture.  The  UNIX 
implementation  was  done  differently  than  that  for  the  Motorola  68020.  Shared  memory 
segments  are  not  attached  to  addresses  within  the  data  section,  as  illustrated  in  Figure 
4.5.  They  are  attached  at  a  much  higher  address,  yet  accessing  them  does  not  result  in  a 
segmentation  violation.  This  is  a  more  robust  technique  that  obviates  any  manipulation 
of  attachment  addresses.  Multiple  shared  memory  segments  are  easily  attached,  using 
default  system  calls.  The  sharedsegment  call  suffices,  even  when  dynamic  memory 
allocation  is  needed.  To  maintain  backward  compatibility  for  application  code, 
dynamicsharedsegment  calls  sharedsegment,  ignoring  the  freespace  parameter,  when 
compiled  on  an  IRIS  4D,  and  calls  attach  within  datasegment  when  compiled  on  an 
older  IRIS  machine. 
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Figure  4.5  IRIS  4D  Default  Shared  Memory  Attachment 


I 

! 

C.  4.3BSD  UNIX 

The  netV.c  file  functions  properly  on  a  4.3BSD  machine  that  is  connected  to  only 
one  network.  The  start  broadcast  function  does  not  properly  handle  multiple  networks. 

I 

;  The  other  functions  work  correctly,  even  when  the  machine  is  connected  to  multiple 

networks. 

i 

All  other  functions  depend  upon  semaphores  and  shared  memory  for 
communication  between  the  spawned  processes  and  the  main  application.  Stream 
sockets21  could  be  used  to  provide  the  EPC  between  these  processes  under  4.3BSD.  The 


21  Unidirectional  stream  sockets  are  equivalent  to  pipes. 
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three  channels22  used  will  have  to  be  multiplexed  into  one,  but  the  implementation  is 
otherwise  straightforward. 

D.  LISP  MACHINES 

The  communication  code  is  a  flavor  to  be  mixed  with  the  application  [Ref.  1 1].  The 
Explorer  software  is  syntactically  equivalent  to  Genera  6  on  the  Symbolics.  With  a 
simple  change  in  the  sequence  of  method  and  flavor  names,  the  Genera  7  code  runs  on 
the  TI  Explorer.  The  older  flavor,  originally  developed  for  the  Explorer,  is  also  presented 
to  illustrate  working  directly  with  TCP/IP  instead  of  using  a  stream. 

1.  Texas  Instruments  Explorer  I 

This  older  flavor  works  with  Release  1 .0  of  the  Explorer  TCP/IP  software.  It 
will  not  work  with  Release  2.0  as  the  implementation  was  changed  from  blocking  to 
non-blocking  [Ref.  27]. 

Messages  to  the  flavors  in  the  ip  package  are  made  together  with  messages  to 
the  tcp  flavors.  Network-independent  addressing  is  not  used.  Table  4.5  describes  the 
addressing  schemes  possible  [Ref.  28:  pp.  4-2 — 4-3].  Class  C  addressing  is  used  by  the 
Computer  Science  Department.  Figure  4.6  shows  the  simple  encapsulation  of  the 
addresses  for  iris l,  iris2,  and  iris3.  Extension  to  include  other  machines  is  easy. 

Table  4.5  INTERNET  ADDRESSING  CLASSES 


Class 

No. 

Networks 

No. 

Hosts 

A 

128 

16,777,216 

B 

16,384 

65,536 

C 

2,097,152 

256 

n  These  are  the  semaphore,  the  message  areas  of  the  shared  memory  buffer,  and  the  data  areas  of  the  shared 
memory  buffer.  The  first  is  unidirectional  from  application  to  spawned  process.  The  second  is  bidirectional  and  three 
state  (see  Table  4.3). 


(defvar  * i r i s  1  - addrea s*  3221866S02) 
(defvar  * i r i s2 - addrea a*  3221866504) 
(defvar  * i r i a3 - addrea a  *  3221866505) 


1 0 


\ 


(defvar  *dest -address*  nil) 


the  tcp-ip  or  internet  address 
look  in  network  configuration 


(defun  iris  (x) 

(cond  ((equal  x  1)  (setq  *de a t - addr e s s *  * i r i s 1  - addre s s* ) ) 
((equal  x  3)  (setq  *de s t - addr e s s *  * i r i »3 - addre s s*  ) ) 

(t  (setq  *de s t - addre s a  *  * i r i s2 - addre s s* ) )  )  ) 

Figure  4.6  Encapsulation  of  IRIS  Addresses 


A  port  is  acquired  by  using  the  :get-port  method  of  the  tcp-handler  flavor. 
Here,  shown  in  Figure  4.7,  we  use  the  global  instance,  *tcp-handler*23  to  create  specific 
instances  of  the  Transmission  Control  Block  (TCB)  for  each  of  the  two  ports.  Only  the 
client  side  of  the  server/client  paradigm  has  been  implemented.  The  client  is  created  by 
using  the  : active  mode  argument  to  the  :open  method  of  the  tcp-port  flavor.  Both  the 
sending  and  receiving  ports  are  full  duplex,  but  are  only  used  in  a  simplex  mode.  Figure 
4.8  shows  the  creation  of  the  sending  port  [Ref.  28:  pp.  4-12 — 4-18]. 

The  three  fields  in  a  message  are  sent  and  received  separately.  Each  field  is 
then  treated  as  a  separate  object.  Figure  4.9  illustrates  sending  a  message.  For  all  fields, 
the  urgent  argument  is  specified  as  nil.  The  push  argument  is  specified  as  nil  until  the 


(defvar  * t cp - hand  I e r 1  *  (send  i p : : ♦ t cp - hand  I e r*  :get-port)) 
(defvar  * t cp- hand  1 e r2*  (send  i p : : * t cp - h and  1 e r *  :get-porl)) 


Figure  4.7  Lisp  Port  Acquisition 


(■end  talking-port  :open 
: ac I ive 

talking -port -number 
deal  inat ion 


tcp  will  begin  the  procedure  to  establish 
connection  (default  va  :paaaive) 
port  number  of  deatination  hoat 
machine  name  or  addreaa  if  blank  and 
in  :paaaive  mode  local  machine  waita  for 
connect i on 

aet  max  aeconda  before  read  requeat  timea  out 


Figure  4.8  Opening  a  Lisp  Client  Connection 


(progn 

(■end  talking-port  :aend 
typebuf fer 
1 

n  i  1 

nil  ) 

(if  (-  (length  lengthbuf fer )  4) 

(aend  talking-port  : aend 
lengthbuffer 
4 

ni  1 
nil  ) 

(progn 

(loopfor  • 1 oopvar i ab 1 e*  (length  lengthbuffer)  4 
(aend  talking-port  :aend  "0"  1  nil  nil)  ) 

(■end  talking-port  :aend  lengthbuffer  (length  lengthbuffer)  nil  nil)  )  ) 
(aend  talking-port  : aend 
buffer 

buffer- length 
t 

nil  )  ) 

Figure  4.9  Sending  a  Message 


data  buffer  is  sent,  when  it  is  specified  as  t.  The  entire  message  is  thus  sent  as  a  unit  to 
the  other  machine. 

2.  Symbolics  36xx 

Genera  7  syntactic  conventions  are  followed.  The  principle  difference  with 
Genera  6  conventions  is  in  the  defmethod  function.  In  Genera  6  (and  the  TI  Explorer), 
the  method  name  follows  the  flavor  name.  In  Genera  7,  the  method  name  precedes  the 


$ 

'.»! 


I 


t 


flavor  name.  Figure  4.10  shows  the  difference.  It  also  shows  the  other  main  difference 
with  the  earlier  code,  that  streams  are  used.  The  use  of  streams  improves  portability  and 
eliminates  the  need  for  the  :reuse-iris  method24.  It  may  be  slightly  slower,  but  any 
difference  has  been  unnoticeable. 

Another  change  was  to  remove  the  dependence  on  hard-coded  addresses.  The 

i 

method  :init-destination-host  was  added  to  the  conversation-with-iris  flavor  (see 

i 

Figure  4.11).  By  using  the  net:parse-host  function,  the  application  need  only  know  the 
name  of  another  machine.  As  network  tables  are  updated,  no  change  to  the  application 
code  is  necessary  unless  a  different  machine  is  desired. 


(defmethod  (conversation-with-iris  :stop-iris) 
(  ) 

(progn  (send  talking-port  :ctose) 

(send  1 i s t en i ng -por t  :close)  )  ) 

Genera  6 

(defmethod  (:stop-iris  conversation-with-iris) 
() 

(progn  (send  t a  I k i ng - s t ream  :close) 

(send  I i s t en i ng - s t r e  am  :  c lose )  )  ) 

Genera  7 

Figure  4.10  Genera  6  and  7  defmethod 


(defmethod  (  : i n i t - des t i na t i on  -  ho s t  conversation-with-iris) 

( name  -  o f - hos  t  ) 

(setf  de s t i na t i on  -  ho s t - ob j ec t  ( ne t : pa r s e - ho s t  name  -  of -hos t  )  )  ) 

Figure  4. 1 1  Generic  Host  Addressing 


u  rhe  '.reuse -Iris  method  is  retained  for  backward  compatibility. 


E.  SUMMARY 

For  UNIX-based  machines,  generic  routines  are  developed  for  semaphore  use, 
shared  memory  use,  and  socket  use.  The  socket  routines  use  both  stream  sockets  and 
datagram  socket c  in  a  simplex  mode  to  provide  directly  connected  client/servers  and 
unconnected  broadcasting  communications.  IRIS  2400,  3120,  and  4D  systems  are  fully 
supported.  4.3BSD  systems  are  supported  with  mid-level  socket  calls  only. 

For  Lisp  machines,  stream-based  functions  are  available  for  direct  connection  as 
clients  only.  Ihese  functions  are  available  directly  if  using  Genera  7  syntax  and  with 
minor  modification  it  using  Genera  6  syntax. 


v.  use  by  Applications 


a.  introduction 

The  application  using  either  direct  connect  or  broadcast  protocol  is  not  concerned 
with  system-level  implementation  details.  Almost  all  aspects  of  shared  memory, 
semaphore,  and  socket  use  are  hidden.  The  number  of  other  machines  to  be  connected 
to,  the  use  of  dynamic  memory  allocation,  and  the  names  of  the  other  machines  are  all 
that  concern  the  application  in  setting  up  a  connection.  The  syucluonization,  or  lack 
hereof,  in  communication  between  machines  is  a  design  decision,  not  a  protocol 
decision. 

B.  Direct  Connect 

A  UNIX-based  machine  can  be  either  a  server,  waiting  for  a  elicit  to  call  and 
establish  a  connection,  or  the  client.  A  Lisp  machine  is  always  a  client. 

1.  UNIX-Based  Machines 

The  functions  provided  for  UNIX-based  machines  are  all  written  in  C.  They 
must  be  linked  into  the  application  program  using  them.  Figure  5.1  is  an  example  make 
file  for  creation  of  an  application  program  on  an  IRIS  system. 

There  are  two  independent  processes,  send  and  receive,  that  are  spawned  to 

•ye 

create  the  sockets  and  monitor  them.  They  are  made  separately  with  the  makefile 
contained  in  their  subdirectory. 


v  See  Appendix  A 
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CFLAGS  =  -Zg  -Im  -g  -p 

SHARE  *»  /work/bar row/share3/ 

MUN  >  caraimu.c 

OBJS  *  First  group  of  . o files 

0BJS1  =  Second  group  of  .o  files 

0BJS2  =  Third  group  of  .o  files 

0BJS3  =  S( SHARE) i o_» j ngl e . o  \ 

$( SHARE )mpa  th  .  o  \ 

$( SHARE)  semaphore  .  o  \ 

$( SHARE) ahareaeg .  o  \ 

$( SHARE) support  .  o 

QBJS4  =  Fifth  group  of  .o  files 

caraimu:  $(MAIN)  $(OBJS>  $(0BJS1)  $(Cf)JS2)  $(0BJS3)  $(OBJS4) 

cc  -o  caraimu  $(MAIN)  S(OBJS)  S(OBJSi)  $(0BJS2)  $(0BJS3)  $(0BJS4)  $(CFLAGS)  -Ibad 

$(MAIN):  const. h  vars.h 

$(OBJS):  const. h  vars.h 

$(<J8JS1):  const. h  objects. h 

$(OBJS2) :  const .h 

$(SHARE)mpat h . o :  $( SHARE) shared. h 

cc  -c  -o  $(SHARE)mpath.o  $ ( SHARE )mp a t h . c  $(CFLAOS) 

$( SHARE) support . o :  S(SHARfi) shared . h 

cc  -c  -o  $( SHARE) suppor t . o  $( SHARE) suppor t . c  $(CFLAGS) 

$( SHARE) semaphore . o : 

cc  -c  -o  $( SHARE) semaphore .o  S(SHARE) semaphore . c  S(CFLAGS) 

$( SHARE) io_s ingl e . o :  $(SHARE) shared . h 

cc  -c  -o  $( SHARE) io_s ingle . o  $(SHARE) i o_s ingl e . c  $(CFLAGS) 

$( SHARE) shareseg.o: 

cc  -c  -o  S(SHARE) share seg . o  $( SHARE) sha re seg . c  $(CFLAGS) 

Figure  5. 1  Sample  Application  make  File 

a.  Application  Setup 

The  server  process  must  be  started  first.  The  application  can  set  up  the 
communications  paths  as  part  of  initialization,  or  it  can  do  so  only  in  response  to  a 


specific  operator  command.  In  either  case,  there  will  be  two  messages  returned  to  the 
terminal  for  each  direct  connection  setup.  Figure  5.2  illustrates  a  normal,  single 
connection,  response.  Since  the  receive  and  send  processes  that  provide  the  messages 
are  independent,  the  two  lines  shown  may  be  jumbled.  A  variety  of  errors  can  occur  at 
this  point.  Table  5.1  gives  the  most  common  error  messages,  their  cause,  and  solution. 


Server  wa  i t ing  to  connect  to  name 
Server  waiting  to  connect  to  name 

Figuic  5.2  Normal  Server  Response 


Table  5 . 1  SERVER  ERROR  RESPONSES 


Message 

Cause 

Solution 

Server  couldn't  open  a  local  socket: 

Socket  in  use  due  to  previ¬ 
ous  run  not  teiminating 
with  deletemachinepath 

1.  ;  J  .ylHf  If 

1 1 1 1  a'  i  iTtTnT^HkBirol 

Server  couldn't  bind  address  to  local  socket: 

Socket  in  use  due  to  previ¬ 
ous  run  not  terminating 
with  deletemachinepath 

Run  ps.  Use  kill  to  ter¬ 
minate  any  receive  or  send 
processes  still  running 

shmget:  Permission  denied 

The  shared  memory  seg¬ 
ment  already  exists,  but  is 
owned  by  another  uid 

Change  key  in 

machinepath  call,  recom¬ 
pile,  and  rerun 

shmget:  Invalid  argument 

The  shared  memory  seg¬ 
ment  already  exists,  but  is 
too  small  because  the  value 
of  LARGESTREAD  has 
been  increased 

Run  rmshare  and  rerun  ap¬ 
plication 

shmat:  Permission  denied 

Someone  else’*  send  or  re¬ 
ceive  process  is  being 
spawned 

Outdated  software  is  being 
used. 

Check  that  proper  path  is 
used  in  shared.h,  for 
application’s  include  of 
shared.h,  and  in 

application’s  Makefile. 

Correct  and  recompile. 

Ensure  that  all  modules  are 
the  most  current.  If  some 
are  not,  get  updated 
modules  and  recompile — 
especially  send  and  re¬ 
ceive. 

The  client  process  must  not  attempt  connection  until  after  the  server  is 
properly  running  (the  messages  in  Figure  S.2  have  been  received).  The  application  can 
set  up  the  communications  paths  as  part  of  initialization,  or  it  can  do  so  only  in  response 
to  a  specific  operator  command.  When  client  communications  setup  is  part  of  die 
initialization,  care  must  be  taken  to  wait  for  a  ready  server  before  starting  the  client.  In 
either  case,  there  will  be  two  messages  returned  to  the  terminal  for  each  direct 
connection  setup  figure  5.3  illustrates  a  normal,  single  connection,  response.  Since  die 
receive  and  send  processes  that  provide  the  messages  are  independent,  the  two  lines 
shown  may  be  jumbled.  A  variety  of  errors  can  occur  at  this  point.  Table  5.2  gives  die 
most  common  ~rror  messages,  their  cause,  and  solution, 
b.  Coding  Practices 

(1)  Connection.  Making  a  connection  requires  two  acts.  The  first  is  to 
set  aside  space  for  the  data  required.  Figure  5.4  shows  this  code  when  local  declaration 
is  used.  The  Machine  structure  can  also  be  declared  globally.  The  second  is  to  request 
the  connection  with  a  machinepath,  dynamicmachinepath,  or  dynamicmachinepaths 
call.  Table  5.3  compares  the  three  types  of  call,  while  Figure  5.5  gives  a  server  example 
for  dynamicmachinepath,  A  description  of  the  parameters  used  is  in  Appendix  A, 


Section  2.a. 


For  flexibility,  there  is  often  a  requirement  for  command  line 


specification  of  the  machine  to  be  connected  to.  For  ease  of  use,  there  is  often  a 


Connection  established  with  name 
Connection  established  with  name 


Figure  5.3  Normal  Client  Response 


Table  5.2  CLIENT  ERROR  RESPONSES 


Message 

Cause 

Solution 

Client  couldn't  open  a  local  socket: 

Socket  in  use  due  to  previ¬ 
ous  run  not  terminating 
with  deletemachinepath 

Run  ps.  Use  kill  to  ter¬ 
minate  any  receive  or  send 
processes  still  running 

Client  couldn't  connect  to  the  remote  server  socket: 

The  server  has  not  success¬ 
fully  started 

The  port  numbers  used  by 
client  do  not  correspond  to 
those  of  server 

Terminate  client,  restart 
server,  restart  client  when 
server  started 

Correct,  recompile,  and 
rerun 

shmgel:  Permission  denied 

The  shared  memory  seg¬ 
ment  already  exists,  but  is 
owned  by  another  uid 

Change  key  in 

machinepath  call,  recom¬ 
pile,  and  rerun 

shmgct:  Invalid  argument 

The  shared  memory  seg¬ 
ment  already  exists,  but  is 
too  small  because  the  value 
of  LARGRSTREAD  has 
been  increased 

Run  rmshare  and  rerun  ap¬ 
plication 

shmot:  Permission  denied 

Someone  else's  send  or  re¬ 
ceive  process  is  being 
spawned 

Outdated  software  is  being 
used. 

Check  that  proper  path  is 
used  in  shared.h,  for 
application’s  include  of 
sharedh,  and  in 

application's  Makefile. 

Correct  and  recompile. 

Ensure  that  all  modules  are 
die  most  current.  If  some 
are  not,  get  updated 
modules  and  recompile — 
especially  send  and  re¬ 
ceive. 

#include  "  /wo  rk/ba  r  rr,  v/  share  3  /  shared,  h" 
ma  i n ( a  rgc , a  rgv ) 

. ************ 

LOCAL  DECLARATIONS 

Machine  cardriver;  /*  structure  for  c ormiun i c a  1 i on  a  syalem  */ 

Figure  5.4  Creation  of  Machine  Structure 


* 

Vi 


Table  5.3  PATH  CONNECTION 


Function 

Purpose 

machinepath 

Creates  a  link  between  two  machines 

No  subsequent  dynamic  memory  allocation  al¬ 
lowed 

dynamicmachinepath 

Creates  a  link  between  two  machines 

Subsequent  dynamic  memory  allocation  allowed 

dynamicmachinepaths 

Creates  a  link  between  two  machines 

Subsequent  dynamic  memory  allocation  allowed 
Multiple  calls  provide  multiple  links  to  one  or 
more  other  machines 

ma  in( argc , a  rgv ) 

. . 

SYSTEM  INITIALIZATIONS 

/*  Open  up  the  net  path  to  other  machine  (iria3  default)  •/ 
dynaniicmachi nepa t h(2 , o t  he  r_mach ine ,4,5, "server" .Acardr i ver , 2000000 ) ; 

Figure  5.5  Server  Creation 


requirement  for  a  default  specification.  Figure  5.6  illustrates  one  way  to  accomplish  this 
for  a  client.  This  example  does  not  require  that  the  network  alias  be  defined  to  the 
system  as  it  uses  the  complete  address.  The  user,  however,  only  enters  the  alias. 

(2)  Program  Use.  The  simplest  high-level  communication  paradigm  is 
reading  from  and  writing  to  the  other  machine.  It  closely  parallels  handling  files  and 
terminals  in  C.  It  was  chosen  for  these  reasons. 

Twelve  high-level  functions  are  available.  Four  provide  status 
information,  four  write  to  other  machine,  and  four  read  from  other  machine .  Table  5.4 
describes  these  functions.  The  parameters  used  by  these  calls  are  described  in  Appendix 
A,  Sections  l.a  and  9. a. 


ma  i  n (a r gc , a r g v ) 


int  argc;  /*  argument  count  */ 

char  *argv[];  /*  pointer)  to  the  passed  in  arguments  */ 

{ 


DATA  DECLARATION 

char  other_machine[50] ;  /*  name  of  other  machine  */ 


SYSTEM  INITIALIZATIONS 

/*  pull  out  the  string  from  the  argument  list  */ 
i f (argc  >  2) 

I 

printf("NAV:  incorrect  argument  count!  use  nav  <alias>\n")j 
exi t (  1 )  ; 

I 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 
iff  argc  ==  2  ) 

( 

strcpy(  other_machine ,  "npscs-"  ); 
s  I  rest (  other_machine  ,  argv[l]  ); 

) 

else 

strcpy(  other_machine  ,  " npsc s - i r i s2"  ); 

/*  Open  up  the  net  path  to  other  machine  (iris2  default)  */ 
dyn  ami cmach i nepa  t h( 2 , o t  he r_mach i ne , 5 ,4 , "c 1 ien  t "  ,&ca r , 2000000) ; 

Figure  5.6  Command  Line  Direction  for  Connection 


There  is  a  variety  of  ways  to  use  these  functions.  Figure  5.7 
illustrates  a  typical  scenario.  This  code  is  from  the  display  station  of  a  two-workstation 
driver  simulation.  The  display  station  provides  its  status  (that  of  the  “world”)  on  each 
pass  through  its  graphical  display  loop.  The  control  station  must  read  that  status  on  each 
pass,  to  update  the  vehicle  position  on  its  track  diagram.  On  each  pass,  the  display 
station  checks  to  see  if  any  commands  have  been  received.  This  is  an  asynchronous 
communication,  as  the  display  station  continues  with  or  without  a  control  station 
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command.  The  asynchronous  reads  are  guarded  by  a  receiver _has_data  call  that  detects 
arrival  of  a  message.  Other  receiver _has_data  calls  are  used  to  "busy  wait”  for  the  next 
message.  In  practice,  it  has  not  been  necessary  to  include  any  but  the  first  “busy  wait” 
receiver _has_data  call.  TCP/IP  buffers  messages  when  they  are  not  immediately  read. 
It  then  blocks  them  into  the  largest  grouping  possible  and  delivers  them  when  the  next 
read  occurs.  The  LARGESTREAD  defined  constant  in  shared.h  determines  this 
maximum  grouping.  The  first  message  is  read  by  receive.  The  socket  is  then  ignored 
until  the  application  reads  the  data.  During  this  time,  the  other  messages  have  all  been 
sent  and  buffered  by  TCP/IP.  There  is  a  slight  delay  between  the  time  the  first  message  is 
read  and  the  block  containing  all  the  rest  is  read.  Thus  the  necessity  for  the  first  “busy 
wait”  receiver  has  data  call.  The  other  “busy  wait”  receiver  has  data  calls  are  simply 
for  robustness. 

The  “busy  wait”  sender Js Jree  call  determines  if  something  has 
happened  to  the  other  machine  or  Ethernet.  The  first  write  will  always  succeed,  as  it  goes 
to  a  buffer.  If  there  is  a  communications  problem,  TCP/IP  will  not  accept  it  and  the 


Table  5.4  COMMUNICATION  FUNCTIONS 


Function 

Action 

sender_is_free 

receiver_has_data 

received_type 

number_rece  ived 

Returns  TRUE  if  a  message  can  be  sent. 

Returns  TRUE  if  a  new  message  has  been  received. 

Returns  a  character  indicating  the  type  of  the  message.  CHARACTERTYPE, 
fNTUOER_TYPE,  and  FLOAT.TYPE  are  predefined.  CHARACTERARRAY_TYPE, 
INTEGER _ARRAY_TYPE,  and  FLOAT_ARRAY_TYPE  are  predefined. 

Returns  an  integer  indicating  how  many  elements  in  message. 

write_character 

write_integer 

write_float 

write_characters 

Send  a  single  value  of  the  type  to  other  machine. 

read_character 

read_integer 

read_float 

read_characters 

Move  single  value  of  named  type  from  buffer  to  application  program  storage. 

main(argc , «rgv) 


MAIN 


S  I  MU  L AT  I  ON 


LOOP 


whi le(vehic le . comnand . condi t ion  1=  DONE) 

( 

;. ,♦♦****♦****♦***. ***♦♦****♦♦♦*****.*.**•♦.♦.**♦*********.***• 

Get  comnands  (if  any)  from  navigator.  Command!  are  all  sent 
or  none  are  sent  so  no  information  is  needed  as  to  which  value 
i  3  i  ch . 

****** . a*,.*.*.******..***.***.*.***.**.*.*. *•••.♦****♦, 


if(  receiver_h»»_data(  Acardriver  )  ) 

( 

read_i n t ege r (Ac a rdr i ve r ,  Aveh i c 1 e . comnand .condition); 
whiie(  I receiver_has_data(  Acardriver  )  )  /*pr in t f ( " 1 " ) */ 
read_i nt eger (Ac a rdr i ver ,  Avehic 1 e . comnand . brakepedal ) ; 
while(  I  receiver. has_data(  Acardriver  )  )  /*pr in t f ( "2" ) */ 
read_inleger(Acardr»ver ,  Aremo t e.mouier ) ; 

while(  I receiver_has_data(  Acardriver  )  )  / *pr in t f ( " 3" ) */ 
read_floa t  (Acardriver ,  Acmdspeed) ; 


a**************************.********. **..*•***•. 

Report  all  status  information  to  navigator  every  cycle. 

. a*****.**.*.**....**.**..*.*.*. . ******** . •*/ 


wr  i  te_floa t (Acardriver ,  Avehic le.state_vector[l]); 
while(  I sende r_i s_f ree (Aca rdr i ve r )  )  pr i n t f ( "b" ) ; 
wr i te.floa t (Ac a rdr i ver,  Avehicle.stat  e_vec  t  or [2] ) ; 
wr i t e_floa t (Ac a rdr iver,  Avehicle. state_vector[3]); 
wr  i  t e_floa t (Ac  a rdr iver,  Aveh icle . si tuat i on. distance_ traveled) ; 
wr it e_ integer (Acardr iver,  Avehicle. comnand .condition); 
write_integer (Acardr iver,  Aveh icle. comnand .brakepedal ) ; 
wr  i t  e_ i n  t  eger (Ac  a  rdr i ve  r ,  Aveh i cle. situation. lightcolor); 


|  /‘while  1 oop  * / 


I 


/*  mi 


n 


*/ 


Figure  5.7  Synchronous  Write  /  Asynchronous  Read 


«it:M  m  »i 


sender  is  Jree  call  will  return  FALSE.  This  often  occurs  when  there  is  a  delay  by  the 
client  in  connecting  to  the  server  (the  display  station  here).  If  there  is  a  good  connection, 
TCP/IP  will  accept  and  buffer  all  input.  No  other  “busy  wait”  calls  are  needed.  The  other 
side  of  the  communication  is  shown  in  Figure  5.8. 

(3)  Disconnection.  Termination,  with  a  deletemachinepath  call  for 
each  path  opened,  is  mandatory.  If  not  performed,  the  sockets  (and  shared  memory 
segment  on  System  V  UNIX  machines)  will  not  be  returned  to  the  system.  Problems26 
may  then  occur  on  the  next  run.  Figure  5.9  is  an  example  termination  when  multiple 
paths  have  been  opened  [Ref.  11], 

2.  Lisp  Machines 

All  necessary  functions  are  contained  in  a  single  file.  This  file  must  be  loaded 
before  use.  Figure  5.10  is  an  example.  A  Lisp  machine  is  always  a  client  and  is  started 
second.  Figure  5.11  illustrates  the  message  returned  with  a  successful  connection. 
Unsuccessful  connections  “hang”  and  return  nothing, 
a.  Connection 

The  address  of  the  server  and  the  ports  it  is  using  must  be  specified. 
Figure  5.12  shows  the  ports  specified  as  part  of  the  loaded  file.  When  using  the  older  TI 
Explorer  functions,  the  addresses  are  specified  in  the  same  way  (see  Figure  4.5)  and  then 
the  machine  des'red  is  requested  by  number27  (shown  in  Figure  5.13).  When  using  the 
stream-based  functions,  the  addresses  are  not  specified  by  the  user  at  all.  The  network 
tables  are  accessed,  by  host  name,  through  the  select-host  function  provided  (shown  in 
Figure  5.14)  Once  the  instance  of  conversation-with-iris  flavor  has  been  completed 


M  See  Tables  5. 1  and  5.2 


11  A  throwback  to  connection  only  with  different  IRIS  machines. 


main(argc , argv) 


whi le(condi t ion  1=  DCNB) 


Receive  ati  statua  information  from  car  every  cycle. 


while(  I receiver_haa_data(  &c a r  )  ) 
read_floa t  (Acar ,  Acy); 
while(  I receiver_has_data(  Acar  )  ) 
read_float (Acar ,  Acx); 
while(  I  receiver_has_dat a(  Acar  )  ) 
read_float (Acar ,  Avelocity); 
wliile(  !  receiver_Kas_data(  Acar  )  ) 
read_float (Acar ,  Ardistance); 
while(  !  rece i ver_ha s_da t a (  Acar  )  ) 
read_i n t ege r (Ac a r ,  Acondition); 
whiie(  i rece i ver_ha*_da t a(  Acar  )  ) 
read_int ege r (Acar ,  Abrakepoa i t ion) ; 
while(  1 receiver_has_dat a(  Acar  )  ) 
read_integer(Acar ,  A1  ightcolor ) ; 


/****************************#*******************»*»**********»■ 

Send  commands  (if  any)  to  car.  Commands  are  all  sent 

or  none  are  sent  so  no  information  is  needed  as  to  which  value 

is  which. 


if(anything  has_changed) 

I 

any thing_has_changed  =  FALSE; 

wri te_integer(Acar ,  Acondition); 

while(  I sender_i s_f ree(  Acar  )  )  printf("a") 

wr i t  e_int ege r (Acar  ,  Abrakepos i t ion) ; 

while(  I sender_is_f ree(  Acar  )  )  printf("b") 

wr i te_in t ege r (Acar ,  Amousex); 

while(  1 sender_i s_f ree(  Acar  )  )  printf(”c") 

wr i t e_floa t (Acar  ,  Acmdveloci ty) ; 

1  /*  i f ( any th ing_has_changed)  */ 


)  /*  while  */ 


|  /*  main  */ 

Figure  5.8  Reciprocal  Synchronous  Read  /  Asynchronous  Write 


dele! emach i nepa t  h (ATI ) ; 
de 1 e I emach i nepa t  h(&S\M3 ) ; 
de  1  e  t  emach  i  nepa  t  h  (AS’KMl )  ; 
deist  emach i nepa t  h  (&SYM4 ) ; 


exi t (  )  ; 


Figure  5.9  Connection  Termination 


;;;  this  is  the  conmun i ca t i on  package 
( I oad  "  i  r  i  sflavor"  ) 


Figure5.10  Loading  Lisp  Flavor 


"A  conversation  with  the  iris  machine  has  been  established" 


Figure  5.11  Lisp  Connection  Message 


( de  f  va  r 
( de  f  va  r 


'irisl-portl*  1027 ) 
'trial  -  port2*  1026 ) 


this  is  the  send  port 
this  is  the  receive  port 


Figure  5.12  Setting  Port  Numbers  with  defvar 


; ; ;  get  the  network  going 
(iris  1  ) 

(setq  ’battle*  (make - i n s t ance  ‘ con ve r s a t i on -wi t h - i r i s ) ) 

(if  (y-or-n-p  "start  networking  7")  (send  ’battle*  rstart-iris)) 

Figure  5.13  Specifying  Server  in  Lisp 


(  se 1 ec  t -hos  t  i r 1 §2 ) 


Figure  5.14  Specifying  Server  by  Name  in  Lisp 


with  port  numbers  and  host  addresses,  the  connection  is  established  with  the  method 
:start-iris,  see  Figure  5.13. 

b.  Program  Use 

The  method  :get-iris  returns  with  the  object  sent  by  one  message.  The 
method  (:put-iris  object)  sends  the  object  as  one  message.  Figure  5.15  illustrates  both. 
Note  how  methods  are  added  to  flavor  conversation-with-iris  to  simplify  the 
application  interface  even  further.  [Ref.  11] 

c.  Disconnection 

Disconnection  is  accomplished  with  the  method  :stop-iris,  shown  in 

Figure  5.16. 

C.  BROADCAST 

Only  UNIX-based  machines  support  our  broadcast  protocol  at  this  time.  It  is  a 
unidirectional  protocol,  but  nothing  prevents  the  establishment  of  two  unidirectional 
channels  in  opposite  directions.  Using  two  broadcast  channels  to  emulate  a  direct 
connect  channel,  however,  loads  all  other  machines  on  the  network  by  requiring  every 
other  machine  to  process  each  message.  It  is  also  less  reliable.  Broadcasting  is  good  for 
sending  status  information  to  many  other  machines,  as  long  as  those  machines  can 
tolerate  missing  reports. 

I.  Similarities  With  Direct  Connect  Protocol  Use 

Using  the  broadcast  protocol  is  similar  to  using  the  direct  connect  protocol. 
The  same  functions  are  used  in  the  same  way.  Each  connection  must  set  aside  space  as 


defini t ions  : 


ob j  ec  t  : 

”n" 

name : 

character  "1”  ..  "5” 

X 

x  coordinate: 

rea  1 

y 

y  coordinate: 

real 

z 

z  coordinate: 

real 

spd 

speed : 

real  speed  of  vehicle  -10.00  to  25.00 

di  r 

di rec  t  ion : 

real  compass  dir  in  degrees  from  ON 

in  lisp 

("n" 

(x  y  z  spd  dir)) 

;;;  get  an  object  in  graphics  environment  (defined  as  above) 

(defmethod  (conversat ion-wi th- i r i s  :object) 

() 

(makeob j 

(send  self  :get-iris) 

( send  self  : get-iris) 

( send  self  : get-iris) 

(send  self  : get-iris) 

( send  self  : ge  t  -  i  r  i  s  ) 

( send  self  : get-iris)  )  ) 

;;;  vision  returns  a  list  of  objects  in  the  tank’s  field  of  vision  (100m  radius) 
;;;  this  is  effectively  an  association  list 

(defmethod  ( conve r s a t i on -wi  t h - i r  i  s  :vision) 

( t  ank ) 

(let  ( (field  ni 1  ) 

(n-objects  0)  ) 

(progn  (send  self  :put-iris  "V") 

(send  seif  :put-iris  tank) 

(if  (equal  "V"  (send  self  : get-iris)) 

(progn  (setq  n-objects  (send  self  :get-iris)) 

(dot ime  s 

( x  n-objects  field) 

(setq  field  (cons  (send  self  :object)  field))  )  ) 

(progn 

(print  "iris  did  not  respond  to  the  vision  command  sent  from  " ) 
(pr inc  ” t  ank  "  ) 

(princ  tank)  )  )  )  )  ) 

Figure  5.15  Application  Communication  in  Lisp 


in  Figure  5.4.  The  same  criteria  for  using  a  specific  machinepath  call  apply  (see  Table 
5.3).  The  same  communications  functions  are  available  as  in  Table  5.4.  Each 
connection  must  be  terminated  as  in  Figure  5.9. 


(if  (y-or-n-p  "stop  iris  connection  7")  (send  *battle*  :stop-iris)) 

Figure  5.16  Termination  of  Communications  in  Lisp 

Differences  With  Direct  Connect  Protocol  Use 
a.  Application  Setup 

The  broadcast  protocol  is  not  directly  modeled  as  a  server/client 
relationship.  The  broadcaster  broadcasts  to  whomever  is  prepared  to  receive.  The 
receiver  must  be  ready  and  so  must  be  started  first.  Since  the  broadcaster  is  more  similar 
to  the  server  in  a  server/client  model,  this  connection  order  seems  exactly  backward.  No 
error  will  result  if  the  broadcaster  starts  first,  messages  will  simply  not  be  received.  The 
receiver  message  is  shown  in  Figure  5.17.  The  broadcaster  message  is  shown  in  Figure 
5.18.  When  a  direct  connect  channel  is  also  required  between  the  same  two  machines, 
achieving  proper  startup  order  is  easy.  Establish  the  direct  connect  channel  first,  then  the 
soon-to-be  broadcasting  process  sends  a  message  telling  the  receiver  to  start  up.  Once 
started,  the  receiver  process  sends  a  message  permitting  the  broadcaster  to  start. 

ready  to  receive  from  broadcaster  name 

Figure  5.17  Normal  Receiver  Response 


b.  Coding  Practices 

The  parameters  to  the  machinepath  family  of  functions  are  used 
differently  for  the  broadcast  protocol.  All  are  required  to  be  present,  but  some  are 
ignored  (see  Table  5.5).  Since  a  broadcast  channel  is  unidirectional,  the  receive  type 
application  calls  are  meaningless  to  the  broadcaster  (the  receiver_has_data  call  always 
returns  false).  The  sendjype  application  calls  are  meaningless  to  the  receiver  (the 
sender  jsjree  call  always  returns  false). 

D.  Summary 

Using  the  same  functions,  an  application  can  either  broadcast  or  directly  connect  to 
another  machine.  The  same  steps  of  setup,  connection,  use,  and  termination  are  common 
to  both  protocols.  Care  must  be  taken  in  the  timing  of  the  two  (or  more)  machines  setup. 


Table  5.5  MACHINEPATH  PARAMETERS 


Parameter 

Function 

machinepath  dynamicmachinepath 

dynamicmachinepaths 

nummachines 

N/A 

Number  of  channels  that  could 
be  created  by  application.  This 
includes  both  DIRECT  CON¬ 
NECT  and  BROADCAST  chan¬ 
nels. 

Arbitrary  integer.  Should  be  different  than  another 
user’s  application. 

Only  first  call’s  value  used. 

miiame 

DIRECT  CONNECT  and  BROADCAST  ( receiver 
only):  Name  of  machine  to  connect  to. 

BROADCAST  (broadcaster  only):  Required  but  ig¬ 
nored 

sendportnum 

DIRECT  CONNECT:  Number  (0-3076)  of  pon  to  be 
used  to  send  to  other  machine. 

BROADCAST  (broadcaster  only):  Number  (0-3076) 
of  port  to  be  used  for  broadcast. 

BROADCAST  (receiver  only):  Required  but  ignored 

receiveportnum 

DIRECT  CONNECT:  Number  (0-3076;  of  port  to  be 
used  to  receive  from  other  machine. 

BROADCAST  (broadcaster  only):  Required  but  ig¬ 
nored 

BROADCAST  (receiver  only):  Number  (0-3076)  of 
port  to  be  used  for  broadcast. 

server 

"server":  Create  DIRECT  CONNECT  channel 

as  a  server. 

"client":  Create  DIRECT  CONNECT  channel 

as:  a  client. 

"broadcast  Create  BROADCAST  charoiel  as  a 

broadcaster. 

"receive":  Create  BROADCAST  channel  as  a 

receiver. 

instructure 

Address  of  Machine  structure  created  to  hold  channel 
information. 

freespace 

I  Amount  of  space  to  be  used  for 

N/A  dynamic  memory  allocation. 

1  ; 

!  |  Only  first  call's  value  used. 

VI.  PERFORMANCE 


A.  Introduction 

We  look  at  the  size  of  packets  from  our  protocols.  We  also  look  at  the  effect  of  real 
applications  on  the  network.  We  try  to  do  this  for  both  direct  connect  and  broadcast 
protocols.  However,  no  application  making  good  use  of  broadcast  protocols  exists. 
Hence,  we  used  a  direct  connect  test  application  and  replaced  the  channel  with  two 
broadcast  channels. 

B.  Data  Collection 

The  LANalyzer*  EX  5500  network  analyzer  was  used  to  gather  Ethernet  statistics. 
Version  2.0  of  the  software  was  used.  The  LANalyzer  5500  is  a  COMPAQ  PORTABLE 
II**  with  a  coprocessor  board  installed.  The  coprocessor  board  has  an  Intel  80286  CPU, 
an  Intel  82586  LAN  coprocessor,  and  two  MBytes  of  memory.  It  performs  packet 
collection,  packet  filtering,  and  network  statistics  calculation.  The  COMPAQ  PORTABLE 
II  processor  handles  user  software  control,  screen  updating  and  disk  I/O.  [Ref.  29] 

Samples  were  taken  while  direct  connect  applications  were  running  on  iris2  and 
iris3.  To  compare  direct  connect  protocol  with  the  broadcast  protocol,  test  programs 

TO 

were  used  .  Table  6.1  summarizes  the  information  collected.  These  programs  send  a 
character  string,  an  integer,  and  a  floating  point  number  in  a  rotating  sequence.  The 
messages  are  either  sent  to  the  machine  specified  on  the  command  line  or  are  broadcast 
to  all  machines  on  the  local  network  but  only  received  from  the  machine  specified. 

*  LANalyzer  is  a  registered  trademark  of  Excelan,  Inc 

**  COMPAQ  PORTABI-F  II  is  a  tradmark  of  the  COMPAQ  Computer  Corporation. 

See  programs  prog  r,  prog2  c,  gprog.r,  and  gprogZ  <  in  Appendix  D. 
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Table  6.1  DIRECT  CONNECT  VERSUS  BROADCAST  STATISTICS 


Run 

Number 

Dirt 

Number 

of 

Packets 

;ct  Connec 
Ave 
Packet 
Size 
(bytes) 

t 

Max 

Test 

Load 

<%) 

B 

Number 

of 

Packets 

roadcast 

Ave 

Packet 

Size 

(bytes) 

Max 

Test 

Load 

(%) 

U 

91 

.10 

9498 

69 

1.0 

mm 

111 

.05 

9860 

69 

1.0 

3 

465 

96 

<.05 

4000 

68 

1.0 

4 

698 

95 

.05 

2556 

68 

1.0 

5 

334 

103 

.10 

1262 

68 

1.0 

The  visual  simulation  application  measured  was  a  modified  version  of  the  driving 
simulator  [Ref.  7].  Table  6.2  summarizes  the  information  collected.  This  data  was 
taken  during  the  day29.  The  application’s  communication  code  is  shown  in  Figure  5.7 
and  Figure  5.8.  One  trip  around  the  track  took  approximately  five  minutes.  Seven 
messages  are  sent  every  cycle  to  report  status.  Four  messages  are  sent  in  the  opposite 
direction,  as  required,  to  control  the  car.  One  circuit  was  driven,  on  autopilot,  for  each 
test  run.  There  were  about  500  cycles  per  test.  Approximately  3600  messages  were 
generated  per  test.  The  number  of  packets  sent  was  less  than  half  of  this.  The  apparent 
discrepancy  exists  for  two  reasons.  First,  each  packet  sent  also  generates  an 


Table  6.2  APPLICATION  NETWORK  USE  STATISTICS 


Run 

Number 

Number 

of 

Packets 

Average 

Packet 

Size 

(bytes) 

Peak 

Network 

Load 

<7c> 

Peak 

Test 

Load 

<%) 

Average 

Network 

Load 

(V 

1 

3747 

89 

13 

.10 

.5 

2 

3297 

39 

11 

.15 

1.0 

3 

4152 

89 

15 

<.05 

.5 

4 

2848 

89 

17 

.15 

.9 

5 

22830 

89 

L  . 

.10 

.3 

”  At  night,  with  less  competition  for  network  r<  'ivei.  the  results  were  similar. 
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acknowledgement  packet  in  return.  By  acknowledging  each  packet,  the  stream  socket 
guarantee  of  delivery  and  proper  sequence  is  met.  Second,  after  the  first  packet 
(containing  the  first  message)  is  received,  the  remaining  three  or  six  messages  are 
immediately  sent.  The  receiving  process  has  often  not  yet  handled  the  first  one.  The 
remaining  messages  are  combined  into  one  and  all  are  read  as  one  block.  This  reduces 
the  interchange  to  a  typical  total  of  four  packets  per  cycle,  two  with  data  and  two  for 
acknowledgement.  Similarly,  four  packets  are  usually  generated  whenever  the  navigator 
process  issues  a  command  sequence  to  the  car. 

An  evaluation  of  a  five-workstation  application  [Ref.  11]  was  also  made.  This 
application  used  three  Symbolics  (syml,  sym3,  and  sym4),  expl,  and  iris2  to  perform  its 
tasks.  Statistics  were  similar  to  the  other  application,  but  the  Symbolics  irisflavor.lisp30 
exhibited  some  problem  behavior.  It  sent  three  packets  for  every  message.  The  first 
packet  contained  the  type  field  only.  The  second  packet  contained  both  the  type  field 
and  the  length  field.  The  third  contained  the  entire  message.  If  a  second  message 
immediately  followed  the  first,  three  more  packets  were  sent,  each  adding  one  field  to  the 
previous  packet.  Only  one  acknowledgement  was  received,  as  all  packets  in  a  group  had 
the  same  identification  number. 


C.  DISCUSSION 

Attempting  to  use  broadcast  protocol  with  the  simple  iest  programs  failed.  One 
problem  encountered  was  overflow  of  the  sending  buffer  within  the  TCP/EP  layers.  The 
rapidity  of  attempted  transmission  was  the  cause.  Higher  network  loading  exacerbated 
the  problem.  When  the  test  application  was  slowed  down  with  printf  calls  (and  the 
output  redirected  into  a  file)  the  buffer  could  keep  up  with  sending  requests.  Using 

10  See  Appendix  C 
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broadcast  protocol  within  a  graphics  display  loop  should  pose  no  problems  unless 
numerous  data  elements  are  transmitted  at  one  time. 


Without  acknowledgement  packets,  broadcasting  put  fewer  packets  on  the  network 
than  did  the  direct  connect  protocol.  When  overall  load  was  haevy,  some  were  lost.  This 
poses  a  serious  problem  for  visual  simulation  applications.  Without  an  elaborate 
application-level  protocol,  the  receiving  process  will  never  know  what  was  intended  to 
be  sent.  Since  only  one  data  object  is  transmitted  at  a  time,  labeling  the  data  objects  is 
difficult.  All  that  is  available  is  to  alternately  send  different  types  and,  after  checking 
the  type  received,  make  a  determination  of  the  likely  intent  of  the  sending  process.  If  a 
block  of  data,  containing  different  types,  could  be  sent  as  a  single  message,  the  decoding 
problem  would  become  one  of  simply  sequence  checking.  Missing  status  packets  can  be 
safely  ignored  in  many  situations.  At  most,  a  simple  averaging  algorithm  can  smooth 
any  discontinuities  caused  by  a  missing  packet.  Timestamping,  with  a  virtual  timestamp, 
of  each  packet  would  eliminate  the  averaging  requirement. 

The  Symbolics  stream  version  is  much  less  efficient,  in  terms  of  network 
utilization,  than  is  the  Explorer’s.  It  still  functions  correctly,  with  no  noticeable  delay. 
As  the  amount  of  data  to  transmit  increases,  the  Symbolics  flavor  will  eventually  have 
noticeable  performance  degradation. 

The  interconection  of  five  machines  loads  the  network  only  slightly  more  than  does 
that  of  two.  The  limitation  will  be  from  the  process  swap  overhead,  not  the  network. 

D.  Summary 

The  direct  connect  protocol  sends  fewer  packets  than  messages.  Half  of  the  packets 
sent  are  acknowledgements.  These  acknowledgements  provide  the  reliability  of  the 
direct  connect  protocol.  The  broadcast  protocol  sends  one  packet  for  each  message. 
These  packets  tend  to  be  smaller  than  those  for  the  direct  connect  protocol.  Until  a 
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vn.  Conclusions  and  recommendations 
A.  Limitations 

There  are  two  primary  limitations.  First,  the  Lisp  and  C  functions  differ  at  the  user 
level.  This  was  done  to  allow  each  to  be  used  readily  by  programmers  “thinking”  in  their 
respective  language.  We  have  found  this  to  be  confusing  to  students  who  are 
inexperienced  in  both  languages.  Second,  there  is  no  simple  means  to  transmit  a  block  of 
data  or  an  entire  file.  Each  data  element,  unless  it  is  part  of  an  array  of  characters,  must 
be  sent  separately.  This  was  done  to  “hit  a  middle  ground”  between  a  complex 
facility — printf  function — and  low-level  system  calls.  As  long  as  only  the  direct  connect 
protocol  existed,  this  was  only  an  annoyance.  As  discussed  in  Chapter  6,  this  is  a 
critically  limiting  factor  for  the  broadcast  protocol. 

The  port  to  BSD  UNIX  systems  without  shared  memory  and  semaphores  was  not 
completed.  The  socket  handling  aspects  are  portable,  but  the  shared  memory  aspects  are 
interwoven  throughout  the  system.  The  difficult  part  of  the  porting  will  be  designing  the 
message-passing  protocol  for  the  pipe  between  the  application  and  the  send  and  receive 
processes,  as  discussed  in  Chapter  4.  Other  specific  limitations  include: 

•  no  broadcast  capability  for  Lisp  machines 

•  no  server  capability  for  Lisp  machines 

•  limited  communication  error  handling — no  signals  are  sent  from  the  send  or 
receive  processes  to  the  application  process  if  they  encounter  problems 

•  limited  read/write  error  handling — a  read  or  write  of  the  wrong  type  will  be 
attempted  and  usually  produce  garbage 

•  no  out-of-band  capability 

•  Symbolics  iris-flavor. lisp  creates  three  packets  per  message 
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B.  Future  Research  Areas 

Implementation  of  the  missing  structure  data  type  is  one  key  area  in  which  more 
work  could  be  done.  The  most  straight-forward  solution  to  this  would  be  to  add 
messages  to  the  send  section  of  the  shared  memory  array  without  signalling  the  send 
process  to  send  it  until  the  entire  block  was  ready.  Such  a  solution  eliminates  any  need  to 
change  the  receiving  functions  at  the  cost  of  either  an  additional  sending  function  or  an 
additional  parameter  to  the  existing  send  functions.  The  additional  send  function  would 
be  a  push  function  and  the  existing  send  functions  would  be  modified  to  never  signal  the 
send  process  to  send.  That  would  be  left  to  the  new  push  function.  Adding  a  parameter 
to  each  send  function  would  allow  any  send  function  to  push.  While  in  some  respects 
simpler,  changes  to  any  application  sending  a  block  of  data  would  have  to  carefully 
monitor  which  send  function  actually  is  pushing. 

Creation  of  a  Lisp  flavor  that  mimics  the  UNIX  functions  would  prove  useful  to  C 
programmers  who  find  a  need  for  Lisp  modules  in  their  visual  simulation.  Adding  server 
and  broadcast  capabilities  would  increase  the  applicability  of  the  protocols  to  future 
visual  simulation  projects.  Functions  to  break  complex  Lisp  objects  into  simple  ones  and 
then  combine  these  into  a  single  message  are  necessary  for  the  broadcast  protocol.  The 
Symbolics  version  should  be  corrected  to  send  a  packet  only  at  message  boundaries. 

C.  Summary  and  Conclusion 

The  routines  described  herein  have  already  proved  useful  to  researchers  at  the  Naval 
Postgraduate  School.  With  Ethernet  loading  never  exceeding  one  percent,  these  routines 
are  efficient  enough  to  use  without  concern.  With  the  additions  mentioned  above,  the 
goal  of  an  easy-to-use  yet  powerful  system  will  be  reached. 


APPENDIX  A  -  IRIS  MODULE  DESCRIPTIONS 


I .  io_single.c 

a.  Calling  Protocols 

This  module  contains  functions  that  are  intended  for  the  application’s  use  and 
functions  that  are  used  exclusively  by  them.  The  parameters  for  externally  accessible 
functions  are  described  below. 

i.  number  received 

numbe r_rece i ved (  instructure  ) 

Machine  * i ns t rue t ure ;  /*  includes 

char  ‘ins t ructure . segment  a  pointer  to  the  shared  segment 

*/ 

ii.  read  character 

read_char ac  t  erf  instructure, charact  e  r  ou  t ) 

Machine  *  ins t rue ture ;  /*  includes 

char  * i ns t rue t u re . segment  a  pointer  to  the  shared  segment  */ 

char  ‘charac t e r_ou t ;  /*  pointer  to  output  character  */ 

iii.  read  characters 

read_characters( instructure, outarray.arraysize) 

Machine  ‘instructure;  /*  includes 

char  4  ins t rue t ure  segment  a  pointer  to  the  shared  segment  */ 
char  outarrayl);  /*  output  character  buffer  */ 

int  arraysize;  /*  the  number  of  characters  to  be  returned  */ 

iv.  read Jioat 

r  e  ad._  f  1  oa  t  (  instructure  ,  f  1  oa  I  _ou  t  > 

M:rch  ine  *  i  ns  t  rue  t  u  re  ;  /*  includes 

char  ‘instructure.se  gnte  n  t  a  pointer  to  the  shared  se  gtne  n  t  *  / 
float  * f 1 oa t _ou t ;  I*  pointer  to  output  float  */ 

v.  read  integer 

read_integer( in structure, integer  out  / 


Machine  ‘instructure;  I*  includes 

char  ‘instructure.se gmc n t  a  pointer  to  'he  shared  s e gme n t  * / 
int  ‘integer  out;  /*  pointer  to  output  integer  */ 
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vi.  receivedjype 

char  received_type(  instructure  ) 

Machine  *ins tructure ;  /*  includes 

char  *ins I  rue ture . segment  a  pointer  to  the  shared  segment 

vii.  write  character 

wr i te_char ac ter( instructure, charac te r_in) 

Machine  *  ins t ructure ;  /*  includes 

char  *ins t rue ture . segment  a  pointer  to  the  shared  segment 
int  ins t rue ture. sendsem  the  semaphore  to  the  sender  */ 
char  *charac ter_in ;  /*  pointer  to  input  character  */ 

viii.  write  characters 

wr i te_charac ters( ins tructure, inarray .array size) 

Machine  *  ins t rue ture ;  /*  includes 

char  *  ins t rue ture . segment  a  pointer  to  the  shared  segment 

int  ins t rue ture . rece i vesem  the  semaphore  to  the  receiver 
char  ♦inarray;  /*  input  character  buffer  */ 
long  arraysize;  /*  the  number  of  characters  input  */ 

ix.  write Jloat 

write_float(instructure,float_in) 

Machine  *  ins t rue ture ;  /*  includes 

char  *  ins t rue ture . segment  a  pointer  to  the  shared  segment 
int  instructure . sendsem  the  semaphore  to  the  sender  */ 
float  *float_in;  /*  pointer  to  input  float  */ 

x.  write  integer 

write_integer(instructure,integer_in) 

Machine  *  ins t ructure ;  /*  includes 

char  *  ins t rue ture . segment  a  pointer  to  the  shared  segment 
int  instructure . sendsem  the  semaphore  to  the  sender  *1 
int  *integer_in;  /*  pointer  to  input  integer  */ 
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^include  "shared. h" 

# i nc 1 ude  "gl  h" 

/*  The  following  routine  copies  a  character  into  the  shared  segment. 
It  puts  the  type  CHARACTER_TYPE  in  the  first  byte  and  the 
length  0001  into  the  next  four  bytes. 

It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 

It  then  sends  a  wakeup  to  the  sender  program. 

It  uses  an  input  structure  since  called  by  main  program 


write_character(instructure,character_in) 

Machine  *inslructure;  /*  includes 

char  *inst ructure . segment  a  pointer  to  the  shared  segment 
int  i n s t rue t u re . sendsem  the  semaphore  to  the  sender  */ 
char  *character_in;  / *  pointer  to  input  character  *  / 

I 

int  msgsize  =  5  +  CHARACTERS  I ZE ;  /*  size  of  message  ♦/ 

char  *sende r * t » r t  =  i  r>  a  »  rnc  t  u  re  -  >segmen  t  +  SEhOEPOFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  S  bytes  of  header  information  */ 
char  *da  t  a start  -  senderstart  +  9; 

long  *sentlength  =  (long  * ) i n s t rue t u re - >segmen t  +  WSEbDEROFFSET; 

/*  insert  the  type  code  */ 

♦(senderstart  +  4)  =  CHARAClERTYPE ; 

/*  insert  the  length  IN  BYTES  of  (he  input  data  */ 
spr i n t f ( ( sende r s t a r t  +  5),  "%04d",  CHARACTER_S I ZE ) ; 

/*  move  the  data  bytes  */ 

memepy  ( da  t  as  t  ar  t  ,  cha r  ac  t  e  r_ i n  ,  CHARACTERS  1  ZE )  ; 

/*  copy  out  the  size  of  the  data  from  the  shared  segment  top  */ 

♦sent  length  =  msgsize; 

/•  at  this  point,  we  send  a  wakeup  to  the  sender  program, 
indicating  that  he  can  reuse  the  shared  segment. 

*/ 

V(  i n  s  t  rue  t u  r e - >send s cm)  ; 

|  /*  wr i t e_cha r ac t e r  */ 
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/*  The  following  routine  converts  an  integer  to  a  string  and  copies  it 
into  the  shared  segment. 

It  puts  the  type  IN'1HUER_TYPE  in  the  first  byte  and  the  string  length 
(in  bytes)  as  an  integer  (in  string  format)  into  the  next  four  bytes 
It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 

It  then  sends  a  wakeup  to  the  sender  program. 

It  uses  an  input  structure  since  called  by  main  program 

*/ 

wr i te_integer( inst  rue  ture , integer_in) 

Machine  *  ins t rue t u re ;  /*  includes 

char  * i ns t rue t u r e  .  segmen t  a  pointer  to  the  shared  segment 
int  ins t rue t ure . sendsem  the  semaphore  to  the  sender  */ 
int  *  in t ege  r_i n ;  /♦  pointer  to  input  integer  *  / 


char  i n t ege r_s t r ing [ 20] ;  /*  string  for  integer  conversion  */ 

int  length;  /*  length  of  integer  string  */ 

int  msgsize;  /*  size  of  message  */ 

char  *senderstart  =  ins t rue t ure ->segmen t  +  SENDEROFFSBT ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  sender.*  I  ar  I  +  9; 

long  *sentlength  =  (long  * ) i n s t rue t u r e - >segmen t  +  W5ENDEROFT3ET; 

/*  convert  integer  to  string  ♦/ 

sprintf(  i n t ege r_s t r i ng  ,  "%dK ,  *integer_in  ); 

/*  find  length  of  integer  string  and  thus  message  */ 
length  =  s  t  r  1  e  n (  i n I ege r_s t r i ng  ); 
msgsize  =  5  +  length; 

/*  insert  the  type  code  */ 

♦(senderstart  +  4)  =  I N I  bG  ERTYPE ; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
sprintf((senderstart  +  5),  "%04d"  ,  length); 

/*  move  the  data  bytes  */ 

mentc  py  (  da  t  a  s  (  a  r  t  ,  i  n  t  ege  r_s  t  r  i  ng  .  length); 

/*  copy  out  the  size  of  the  data  from  the  shated  segment  top  */ 
♦sentlength  =  msgsize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 
indicating  that  he  can  reuse  the  shared  se  gme  n  t  . 

*/ 

V(  inst  ructure  -  -»s  endsem)  ; 
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/*  The  following  routine  converts  a  float  to  a  string  and  copies  it 
into  the  shared  segment. 

It  puts  the  type  FLGVT_TYPE  in  the  first  byte  and  the  length 

(in  bytes)  as  an  integer  (in  string  format)  into  the  next  four  bytes 
It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 

It  then  sends  a  wakeup  to  the  sender  program. 

It  uses  an  input  structure  since  called  by  main  program 

*/ 

wri te_floa! ( in  structure, float_in) 

Machine  * i n s t r uc t u re  ;  /*  includes 

char  * i ns t r uc t u r e . s egmen t  a  pointer  to  the  shared  segment 
int  i n s t rue t u r e . sendsem  the  semaphore  to  the  sender  */ 
float  *float_in;  /*  pointer  to  input  float  *  / 

( 

char  f 1 oa t _s t r i ng [ 30 ] ;  /*  string  for  float  conversion  */ 

int  length;  / *  length  of  float  s  t  r :  "  g  *  / 

intmsgsize;  /•  size  of  message  */ 

char  ‘senderstart  =  i n s t rue t u re  - >segme  t  +  SEN3EROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  senderstart  +  9; 


long  *sentlength  =  (long  * ) i n s t r uc t u re - >segmen t  +  WSEMJEROFFSET ; 


/*  convert  float  to  string  */ 

sprintf(  float  string.  "%f "  ,  *float_in  ); 


/*  find  length  of  float  string  and  thus  message  */ 
length  =  si  r  len(  float_string  )  ; 
msgsize  =  5  +  length; 


/  •  insert  the  type  code  *  / 
•(senderstart  +  4)  =  FLQAT_TYPE ; 


/•  insert  the  length  IN  BYTES  of  the  input  data  */ 
sp r i n t f ( ( s ende r s I  a i t  +  5).  "%04d"  ,  length); 


/*  move  the  data  bytes  */ 

memo  py (data  start,  float_string,  length); 


/♦  copy  out  the  size  of  the  data  from  the  shared  segment  top  */ 
•sent  length  =  msgsize; 


/*  at  t  h i 8  point,  we  send  a  wakeup  to  the  sender  program, 

tiie  shared  se  gme  n  t  . 


'/ 


indicating  that  he  can  reuse 


V(  inst  ructure->sendsem) ; 
/*  wri te  float  •/ 
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/*  This  routine  returns  the  type  of  data  received.  */ 
char  rece ived_type(  instructure  ) 

Machine  * i ns t rue t ur e ;  /*  includes 

char  *ins t rue t ure . segmen t  a  pointer  to  the  shared  segment 

( 

return!  * ( i n s t r uc t ur e ->segmen t  +  RECEIVEROFFSET  +  4)  ); 
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/*  This  routine  returns  the  number  of  data  items  received.  */ 
nunibe  r_rece  i  ved(  instructure  ) 

Machine  *  i  n s t r uc t u r e ;  /*  includes 

char  *  ins t rue ture . segment  a  pointer  to  the  shared  segment  */ 
i  n  t  t  entp_  i  n  t  ; 

char  ‘protocolhold  =  i n s  t  rue  t u re ->s egmen  t  +  PRCHTXBLHXDOFFSET ; 
long  *pa r t rece i ved  =  (long  * )p ro t oco 1  ho  1 d ; 

long  ‘recei  vedlength  =  (long  *) i n s t rue t u re - >s egmen t  VRECEIVEROFFSET; 

char  * rece  i  ve r s t a r t  =  i n s t rue t u re ->s egmen t  +  RECEIVEROFPSET; 

/*  check  if  only  part  of  protocol  information  received  */ 

if(  * rece i vedl eng t h  <  5) 

1 

/*  move  data  received  (as  well  as  length  field)  to  holdirg  area  */ 
mentcpy(  protocolhold,  rece  i  ve r s t a r t  ,  * rece i ved 1  eng t h  +  4  ); 

/*  get  next  message(s)  */ 
f  ree_rece  iver(  inst  ructure->se  gme  n  t  )  ; 

V ( inst  ructure->receivesem) ; 

whi  le(  receiver_is_free( instructure->se  gme  nt)  )  /‘wait  *  /  ; 

/*  copy  rest  of  protocol  data  into  holding  area  */ 
ntemcpy(  (protocolhold  +  *pa r t rece i ved  +  4),  (receiverjtarl  +  4), 

(5  -  *partreceived)  )  ; 

I 

else 

( 

/*  copy  protocol  data  into  holding  area  */ 
mentcpy(  protocolhold,  rece  i  ve  r  s  t  a  r  t  ,  9); 

/*  initialize  *par t rece i ved  so  it  can  be  used  later  •/ 

*pa  r  t  rece i ved  =  0; 

1 

/*  determine  the  length  of  the  received  integer  string  and  thus  message 
sscanf(  protocolhold  +  5,  "%d".  &temp_int  ); 

switch!  ‘(protocolhold  +  4)  ) 

I 

case  CHARACTER„TYPE : 
re  t  u  rn (  1  )  ; 

break; 

case  I NTEGER  TYPE  : 

return!  1  )  ; 

break; 

case  FLQAT_TYPE : 

return!  1  )  ; 

break; 

case  ( T1AR ACTER _ ARRAY_TYPE 

return!  *  emp_  i  n  t  /  CHARACI  ER_S  1 ZE  )  ; 
break; 

case  (NTEfiER  ARRAY  TYPE . 

return!  t  emp_  i  n  t  /  lNTETiER_S  I  ZE  ); 
break  ; 

case  FLGAT_ARRAY_TYPE . 

return!  t  emp  i n  t / PL0AT_S I ZE  ) ; 

I 

|  /  *  n  umb  er  received  *  I 
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/*  The  following  routine  returns  a  character  from  the  shared  segment 
It  frees  the  receiver  side  of  the  shared  segment  if  it  is  empty. 
It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  catted  by  main  program. 

*/ 


read_character(instructure,character_out) 


Machine  *  i n s t r uc t u r e ;  /*  includes 


char  *  i  n s t rue t u r e . segmen t  a  pointer  to  the  shared  segment  */ 


char  *cha rac t e r_ou t ;  /*  pointer  to  output  character  */ 


/*  temporary  storage  for  move  of  received  data  or  for  protocol  information 
when  partial  receipt  *  / 
char  I  emp  [  LARG  ESTREAT)  ]  ; 


char  *p  r  o  t  oc  o  1  ho  !  d  =  i  n  s  t  r  uc  t  u  r  c  -  >  s  egmen  t  +  PRCfTOCX)LHOLDOFFSET ; 


/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *pa r t r ec e  i  ved  =  (long  * )p ro t oco 1  ho  1 d ; 


i n  t  ms  g  s i z  e 


5  +  CHARACTER_S I ZE ;  /*  size  of  message  */ 


char  ’receiverstart  =  i n s t r uc t u re  - > s egmen t  +  RECEIVEROFFSET; 


/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  ’datastart  =  receiverstart  <-  9; 


long  *receivedlength  =  (long  *  |  inst  ructure  -  >segmen  t  +  ^^RECEIV3ROFFSET ; 


/*  check  if  first  part  of  protocol  information  i»  oissing  */ 
iff  *pa r t r e ce i ved  ==  0  ) 


/*  check  if  only  part  of  protocol  information  received  */ 
if(  * r ec e  i  ved  I  eng t h  <=  5) 


/•  move  data  received  (as  well  as  length  field)  to  holding  area  */ 
memcpy(  proto col  hold,  receiverstart.  ’receivedlength  +  4  ); 


/  ’  get  next  message) s)  *  / 
free_recciver( instruct  urease gme  n I  ) ; 

V(  inst ructure  >rcce i ve sem) : 

whi  le(  receive  r_i !_f  ree( inst  ructure ->se gme  n  t  )  )  /‘wait  *  / 


/*  reset  nisgsize  and  datastart  to  correspond  to  partial  receipt  */ 
msgsize  -=  *part received; 
datastart  -=  ‘partreceived; 


/ *  move  the  bytes  •  / 

memc  p  y  (  c  h  a  r  a  <■  t  e  r  _  o  u  t  ,  datastart  ,  CHARAC1ER_  S  I  ZE  ) 


/*  make  buffer  ready  for  next  read  */ 

reset,  buffer!  teceivedlength.  ms  g  s  i  <  e  .  in  strut-  ire,  datsslart, 
CHARACTER  S 1 7£  ,  partreceived.  receiverstart  I: 


j  '•  *  read  character  *  / 


.  j-  y*  y  y  y 
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/*  The  following  routine  converts  a  string  in  the  shared  segment 
into  the  returned  integer. 

It  frees  the  receiver  side  of  the  shared  segment  if  it  is 
It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  called  by  main  program. 


read_ integer! instructure, intege  r_ou t ) 


Machine  *  in s t rue t ure ;  /*  includes 


char  *  in s t rue t u re . s egmen t  a  pointer  to  the  shared  segment  */ 


int  * i n t ege r_ou t ;  /*  pointer  to  output  integer  */ 


char  in i eger_s t r i  n  g  [  LARGESTREAD  ] ;  /*  string  storage  for  received  data  */ 


char  *pr o t oco 1  hoi d 


instructure->se  gment  +  PROTOOOLHDLDOFFSET ; 


/*  first  four  bytes  of  holding  area  as  integer  */ 
long  "part  received  =  (long  *  )  p r o t oc o 1  hoi d ; 


int  length; 


/  *  length  of  integer  string  read  *  / 


long  segmen t I  eng t h ; 


/*  length  of  data  of  partial  massage  */ 


int  ms  gs  i  ze  ; 


/  *  size  of  message  ♦/ 


char  * r ec e i ve r s t a r t  =  instruciure-isegmeni  +  RECEIVEROFFSET; 


/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  ’dataatart  =  receiverstart  -t-  9; 


long  *receivedlength  =  (long  * ) i ns t rue t u re - >segmen t  +  \MfECEIVERDFFSET; 


/*  determine  proper  protocol  info  and  reset  variables  if  necessary  */ 
get_protoco!(  protocolhold,  partreceived,  received]*. ngth,  receiverstart 
instructure,  &length,  Amsgsize,  &datastart  ); 


/*  check  if  only  part  of  data  has  been  received  */ 


iff  ‘receivedlength  <msgsize  ) 


get_data(  As  egnien  t  1  e n^  t  h  ,  rece i ved 1  eng t h  ,  partreceived, 
inteaer_f tring,  Ada  lay  tart,  Amsgsize, 
receiverstart,  instructure,  Alength); 


/  *  convert  ti  string  *  / 

i  n t ege r_ » t r  i  ne ( segmen 1 1  eng t h  +  msgsizej  =  ’\0’; 


/*  move  the  integer  siring  bytes  */ 
memepy ( i n t ege r_s t r i ng ,  datastart,  length); 


/  *  convert  to  string  *  / 
i n t e ge r _ s • r i ng f I e ng t h  ]  =  ’ \0 '  ; 


I  *  convert  the  received  string  to  an  integer  *  / 
sscanf(  integer_string,  "%d "  .  integeroit  ); 


/*  make  buffer  ready  for  neai  lead  */ 

resetbufferl  receivedlength,  ms^size,  instructure,  datastart,  length, 
partreceived,  receiverstart  ); 


/  *  read  integer  *  / 


v;  •  y.y.  s 


■  -  *._*  Aj*  1  l  *  a  *  i  'Jt’j  V*.  *  ji  M  *  Vji  V  \jf* 
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/♦  The  following  routine  converts  a  string  in  the  shared  segment 
into  the  user  supplied  float. 

It  frees  the  receiver  side  of  the  shared  segment  if  empty. 

It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  called  by  main  program. 

*/ 

read_float(instructure,float_out) 

Machine  *  i n s t r uc t u re ;  /*  includes 

char  *  ins t rue t u re . segmen t  a  pointer  to  the  shared  segment  */ 

float  *float_out;  /*  pointer  to  output  float  */ 

( 

char  float_8t  ring [  LARGEST  1 READ ] ;  /*  string  storage  for  received  data  */ 

char  *protocolhold  =  i n s t r uc t u r e ->segmen t  +  PROTOOOLHOLDOFFSET ; 

/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *partreceivcJ  =  (long  *)protocolhold; 

int  length;  /*  length  of  float  string  read  */ 

long  segmen t I  eng t h ;  /*  length  of  data  of  partial  massage  */ 

int  msgsize;  /*  size  of  message  */ 

char  *receiverstart  =  i n s t r uc t u r e - >a egmen t  +  RECEIVEROFFSET; 

l*  the  +  9  is  to  s'ltp  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  r ec e i ve r s t a r t  +  9; 

long  * r ece i ved  1  eng t h  -  (long  *)  i n s t rue t u re - >s egmen t  +  WRECEIVEROFFSET; 


/*  determine  proper  protocol  info  and  reset  variables  if  necessary  */ 
get  prolocol (  p ro t oco 1  ho  1 d ,  pa r t r e c e i ved ,  rece i ved  1  eng t h ,  r ece  i  ve r s t a r t  , 
instructure,  &length,  dtmsgsize,  &datastart  ); 

/*  check  if  only  part  of  data  has  been  received  */ 
iff  * rece i ved 1  eng t h  <  msgsize  ) 

I 

get_data(  &s egmen t  I  eng t h ,  r ec e i ved 1  eng t h  ,  pa r t rece i ved  , 
float_string,  &datastart,  Smsgsize, 
r ece  i  ve r s t a r t  ,  instructure,  &length); 

/*  convert  to  string  */ 

f 1 oa t _ s t r i ng [ segmen ! ! eng t h  +  msgsize]  =  ’\0‘; 

1 

else 

1 

/*  move  the  float  string  bytes  */ 
niemc  py(floa!_string,  datastart,  length): 

/*  convert  to  string  */ 
float  st  ring] length]  =  ’\0’; 

I 

/*  convert  the  received  string  to  an  float  */ 
s  s c  a n  t  (  I  l  o a  t  string,  "tf< t  "  ,  t  loa  t  out  )  ; 

/*  make  buffer  ready  for  next  rend  */ 

r e s e t _bu f f e r (  re  eivedlength,  msgsize,  instructure,  datastart,  length, 
par l received,  receiverstait  ); 


)  /  *  read  flint 
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/•  The  following  routine  copies  characters  from  an  array 
into  the  shared  segment. 

It  puts  the  type  CHARACTER_ARRAY_TYPE  in  the  first  byte  and  the 
array  length  (in  bytes)  as  an  integer  into  the  next  four  bytes. 

It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 

It  then  send*  a  walceup  to  the  sender  program. 

It  uses  an  input  structure  since  called  by  main  program 

*1 

write_characters(instructure, inarray, array size) 

Machine  *  in s t rue t u re  ;  /*  includes 

char  *  ins t rue  lure . segmen t  a  pointer  to  the  shared  segment 
int  ins t rue t ure . rece i vesem  the  semaphore  to  the  receiver.  */ 
char  *inarray;  /*  input  character  buffer  */ 
long  arraysize;  /*  the  number  of  characters  input  */ 


int  datasize  =  arraysize  *  CHARACTER^ SIZE;  /*  size  of  data  field  */ 

int  msgsize  =  5  +  datasize;  /*  size  of  message  */ 

char  *senderstart  =  i ns t rue t ure - >segmen t  +  SEN3EROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *dalastart  =  senderstart  +■  9; 

long  •sentlength  =  (long  *  )  i  n  s  t  r  uc  t  ure ->segmen  t  +  \M5EMSROFFSET; 

/*  insert  the  type  code  */ 

•(senderstart  +  4)  =  CHARACTER_ARRAY_TYPE ; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
spr  i  n t f  ( (  sende r s t a r t  +  5),  "%04d",  ( i n t  )  da t a s i ze ) ; 

/*  move  the  data  bytes  •/ 

memepy ( ( da t a s t a r t ) ,  inarray,  datasize); 

/•  copy  out  the  size  of  the  data  from  the  shared  segment  top  •/ 

•sen  tlengt’'  =  5  +  datasize; 

/•  at  this  point,  we  send  a  wakeup  to  the  sender  program, 
indicating  that  he  can  reuse  the  shared  segment. 

*1 

V( instructure->sendsem); 

)  /•  wr i t e_cha r ac t e r s  •/ 
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/*  The  following  routine  copies  bytes  from  the  shared  segment 
into  the  user  supplied  array, 

It  frees  the  receiver  side  of  the  shared  segment  if  it  is  empty. 
It  then  sends  a  wakeup  to  the  receiver  progr am . 

It  uses  an  input  structure  since  called  by  main  program. 


rea d_ characters! instructure, outarray.arraysize) 

Machine  *  i  n s t rue t u r e ;  /*  includes 

char  ‘ins  I ructur:. regment  a  pointer  to  the  shared  segment  */ 
char  outarrayf];  /*  output  character  buffer  */ 


i  n  t  a  r  r  ay s i ze  ; 


/*  the  number  of  characters  to  be  returned  */ 


char  *p r o t oc o 1  ho  1 d  =  i  ns  t  rue  ture-xegment  +  PROTOODLHOLDOFFSET; 

I*  first  four  bytes  of  holding  area  as  in'-ger  */ 
long  ‘part  received  =  (long  * )pr o I ocol hoi d ; 


i  n  t  length; 

long  segmen t 1  eng t h ; 


/*  length  of  character  string  read  */ 

/  *  length  of  data  of  partial  massage  */ 


int  datasize  =  nrraysize  *  CHARACTER_S 1ZE ;  /*  size  of  requested  data  field  */ 


i  n  t  reque  s  t  s  i  ze; 

int  msgsize  =  5  +  datasize; 


/*  size  of  mess  age  */ 

/  *  size  of  requested  me  s  s  a  g  e  * / 


char  *  r  ece  i  ve  r  s  t  a  r  t  =  i  ns  I  rue  t  u  r  e  -  >segnten  t  +  RJECE1 VEROFFSET ; 

I*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *  d  a  t  a  start  =  receiverstart  +  9; 

long  *  r  e  c  e  i  ve  d  I  eng  t  h  =  (long  *  )  i  n  s  t  r  uc  t  u  re  -  >segmen  t  +  ^^RECE^VEROFFSET; 

/*  determine  proper  protocol  info  and  reset  variables  if  necessary  */ 
g  e  t  _  p  r  o  t  o  c  o I (  protocol  hold,  partreceived,  receivedlenglh,  receiverstart, 
instructure,  &length,  <Smsgsize,  &datastart  ); 

I*  check  if  all  of  data  (or  more)  was  requested  */ 

if(  length  <=  arraysize  ) 

I 

/*  check  it  only  part  of  data  has  been  received  */ 
iff  ‘receivedlenglh  <  ntsgsize  ) 

I 

ge  t  _dn  t  a (  &i egmen  length,  received  length,  partreceived, 
out  array.  Adatastart  ,  Antsgsize, 
receiverstart,  i  ml  rut  lure,  &d  a  t  a  s  i  z  e  )  ; 


/*  move  the  character  bytes  */ 
memepy ( on  t  a  t  r  a  y ,  d  a  t  a  s  I  a  t  t  .  length', 

1 

/*  make  buffer  ready  for  nest  read  */ 

reset  buffer!  received  length,  ms  gstze,  inst rurtute,  dnlnstart,  datasize, 
partreceived.  re c civet  start  )  , 


VaK'.'aV.'.-'.V.v'.-.'.'. 
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else 

( 

/*  move  the  byte*  */ 

memcpy( out  array  ,  dataatart,  dataaize); 


) 


/*  make  buffer  ready  for  next  read  */ 

reaet_buf fer(  recei vediength ,  midsize,  inatructure,  dataatart,  dataaize, 
par t rece i ved ,  r ece i ve r a t a r t  ); 

) 

/*  read_charac t era  */ 
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/•  These  are  various  support  routines  used  by  several  of  the  preceding 
f  unc  t  ions  . 

*/ 

r e se t _bu f f e r ( r ece  i  ved 1  eng t h  ,  msgsize,  instructure,  datastart,  datasize, 
pa r t rece i ved ,  receiverslart) 

long  ♦ rece i ved  1  eng t h  ;  /♦  first  four  bytes  of  receive  part  of  shared  seg  */ 

int  msgsize;  /*  size  of  me  ssage  read  *  / 

Machine  * i n s t rue t u r e  ;  /*  includes 


char  * i n s t rue t ur e . segmen t  a  pointer  to  the  shared  segment 

int  instructure , receivesem  the  semaphore  to  the  receiver.  */ 


char 

♦datastart  ; 

/* 

address  data  starts 

i  n 

receive 

part 

of  shared  seg 

i  n  t 

datasize; 

/* 

length  of  data  part 

o  f 

me  ssage 

*/ 

long 

♦part  received; 

/* 

length  of  me  ssage  recei 

ved  in 

previous  block  ♦/ 

char 

♦rece iverstarl  ; 

/* 

address  receive  pari 

o  f 

shared 

seg 

starts  * / 

1 

r 

h  n  r  !  emp  j  LARGESTREAD  ]  ; 

l  / *  t empo r a r y  stors 

foi  uiuve  of 

received  data 

/*  free  the  receiver  segmrnl  if  this  is  only  message  received  ♦/ 
if(*receivedlength  ==  msgsize) 

I 

f  ree_receiver( inst ructure->se gme n I  )  ; 

/*  at  this  point,  we  should  send  a  wakeup  to  the  receiver  program, 
indicating  that  he  can  reuse  the  shared  segment. 

*/ 

V (  inst  r  u  c  t  u  t  e  -  >  r  e  c  c  i  v  e  s  er.i )  ; 


else  /*  shift  data  forward  in  shared  memory  segment  */ 

( 

•receivedlenglh  ■=  msgsize; 

me  me  py  (  t  enip  ,  (datastart  +  d  h  t  a  s  i  /  c  )  ,  (I  -AKGESTREAD  ms  g  s  i  z  e  )  )  ; 
memepy  ((receiverslart  +  4),  t  emp  ,  t  L.ARG  ESTREAT)  ms  g  s  i  t  e  )  )  ; 

I 

/*  reset  "part  received  for  next  read  */ 

•part  received  —  0, 

/  *  reset _ buffet  ♦  / 
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ge t _p r o t oco I (  pro t oco 1  hot d ,  pari  received,  receivedlength,  receiver* I ar I  , 
instructure,  length,  magsize,  datastart  ) 


/*  protocol  holding  area  */ 

/*  length  of  menage  received  in  previou*  block  */ 

/*  fir*t  four  bytes  of  receive  part  of  shared  seg  */ 
/*  address  receive  part  of  shared  seg  starts  */ 


char  ’protocolhold; 
long  *pa r t rece i ved ; 
long  *  received  length; 
char  ’receiverstart ; 

Machine  *  ins t rue t u re  ;  /’  includes 

char  *  ins t rue t ure . segmen t  a  pointer  to  the  shared  segment 
int  inst ructure . receivesem  the  semaphore  to  the  receiver.  */ 
int  ’length;  /*  length  of  data  field  in  message  */ 

int  ’msgsize;  /*  length  of  message  ’/ 

char  ’’datastart;  /*  address  data  starts  in  receive  part  of  shared  seg  */ 


/*  check  if  first  part  of  protocol  information  is  missing  ’/ 
if(  ’par t rece i ved  ==  0  ) 

I 

/’  check  if  only  part  of  protocol  information  received  */ 
if(  ’receivedlength  <=  5) 

( 

/’  move  data  received  (as  well  as  length  field)  to  holding  area  */ 
memcpy(  pro t ocolhol d ,  rece i ve r s t a r t  ,  ’receivedlength  +  4  ); 

/*  get  next  message(s)  */ 
free_receiver(instruc  t u re  - >segmen t ) ; 

V( ins  t  rue  ture->recei vesem) ; 

wh i 1 e (  rece iver_i s_f ree( ins t rue ture->segment )  )  /♦  wait  •/  ; 

/*  copy  rest  of  protocol  data  into  holding  area  */ 

memc  p  y (  (pro t oco I  ho  I d  +  *pa r I r ece i ved  +  4),  ( rece i ve r a t ar t  +  4), 

(5  -  ’par t rece i ved)  ); 

) 

else 

( 

/*  copy  protocol  data  into  holding  area  */ 
memcpy(  pro t ocol ho  1 d ,  rece i ve r s t ar t  ,  9); 

/*  initialize  *pa r t rec e i ved  so  it  can  be  used  later  */ 

’pa r t rece 1 ved  =  0; 

I 

) 

/*  determine  the  length  of  the  received  data  string  and  thus  message  ’/ 
sscanf(  protocolhold  +  5,  "%d",  length  ); 

’ntsgsize  =  5  +  ’length  -  ’par  t  rece  i  ved  ; 

/*  reset  datastart  to  compensate  for  possible  partial  receipt  ’/ 
’datastart  -=  ’partreceived; 


I  /*  get_protocol  ♦/ 
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get_data(  segmen I  I  eng t h ,  r ec e i ved  I  eng t h  ,  par  I  received,  s t r 1 ng_a r r ay , 
datastart,  msgsize,  receiverstart,  instructure,  datasizc  ) 

long  * s egmen t I  eng  I h ;  /*  length  of  partial  data  */ 

long  * r ece i ved I  eng t h  ;  /’  first  four  bytes  of  receive  part  of  shared  seg  */ 

long  ’par t rece i ved ;  /*  length  of  message  received  in  previous  block  */ 

char  string_array[j;  /  *  storage  for  i ncomi  ng  characters  *  / 

char  ’’datastart;  /  *  address  data  starts  in  receive  part  of  shared  seg 

int  *msgs  i  ze •  /*  length  of  message  */ 

char  ’receiverstart;  /  *  address  receive  part  of  shared  seg  starts  *  / 

Ma  chine  * i n structure;  /  *  includes 

char  * i n s t r u c t u r e . s egmen t  a  pointer  to  the  shaied  segment 
int  i n s t rue t u r e . r ec e i ve sent  the  semaphore  to  the  receiver.  */ 
int  ♦  d  a  t  a  s  i  z  e  ;  /  *  length  of  data  field  in  me  s  s  a  g  e  *  / 

I 

/*  determine  length  of  data  that  has  been  received  */ 

*  s  e  gme  ntlength  =  *receivedlength  -  +  ’psrtreceived; 

/’  copy  the  fivst  segment  of  data  to  holding  array  */ 
menicpyl  strings array,  ’datastart  ,  * segmen t  1  eng t h  ); 

/*  reset  msgsize  and  datastart  to  correspond  to  partial  receipt  */ 
’msgsize  -=  * s egmen t  I  eng t h  +  5  -  ’part  received: 

•datastart  =  receiverstart  +  4; 

/*  get  next  ntessage(s)  ’/ 
f  ree_recei  vei  (  ins!  racture  ■>«  gme  n  t  )  , 

V<  inst  rue ture ->recr i veseml  : 

while!  receiver,  i  s_f rce( inst  ructuie  >segmenl)  )  /’wait  */  ; 

/*  cycle  through  ns  many  messages  as  it  takes  ’/ 
while!  ’receivedlength  <  ’msgsize  ) 

( 

/*  copy  the  next  segment  of  data  to  holding  array  */ 

menu  pyt  Aslring_array|*»e gme n I  1 c n g I h |  ,  ’datastart,  ’receivedlength  )  ; 
/*  reset  msgsize  and  * egmen ! I  eng t h  < "  correspond  to  partial  receipt  */ 

’msgsize  *  tree  i  vr.t  i  r  iijt !  I]  ; 

*  s  e  gme  ntlength  - =  ’receivedlength: 

/  *  get  next  mess  a gets)  *  / 

free  r  e  c  e  i  v  e  r  t  i  n  s  t  r  u  c  t  n  i  e  •  v  <■  gme  nil, 

V(  int  t  oic  t  lire  -"receives  eni  t  : 

wh i  1 e (  receiver  i#  frtet  mil mcluie  zse gme  nl)  )  /  *  wait  *  /  ; 

I 

/’  copy  the  last  segment  of  data  t o  holding  array  */ 

memo  pyt  <%s  t  r  i  n  g  a  i  r  a  y  I  *  s  e  gme  n  t  I  e  n  g  I  n  J  ’datastart.  ’,*.is  g  s  i  z  e  )  : 

/  *  reset  d  a  I  a  s  t  /  e  to  properly  * e I  I r  y  t  last  segment  size  * / 

’  "1 1.  I  a  s  t  /  c  -  ’m>  g  s  i  z  e  ; 


2.  mpath.c 


a.  Calling  Protocols 


All  functions  in  this  module  are  meant  to  be  accessible  by  the  application. 
These  functions  set  up  and  tear  down  the  communications  path  between  two  machines, 

i.  deletemachinepath 


de J e I emach i nepa t h( initructure) 


Machine  *i ns t rue ture ;  /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue t ure . segmen t  --  returned  ptr  to  the  shared  segment, 
int  ins t rue t ure . shmid  --  returned  system  generated  shared  mem  id 
int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 
int  inst ructure. receivesem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 

*/ 


ii.  machinepath 


machinepath( segmen t num.mname  ,  sendpor  tnum.receivepor  t num,  server, instructure) 

long  segmentnum;  /*  the  key  to  use  for  the  created  shared  segment  */ 
char  mname[];  /*  machine name  character  string  */ 

long  sendportnum,  rece i vepor t num;  /*  send  and  receive  port  numbers  */ 

char  server!];  I*  this  character  string  is  either  "client"  or  "server". 

It  indicates  whether  the  sende r / rece i ve r  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server  . 

*/ 

Machine  * i ns t r uc t u r e  ;  /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue ture . segmen t  --  returned  ptr  to  the  shared  segment, 
int  inst ructure . shmid  --  returned  system  generated  shared  mem  id 
int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 
int  i n s t rue t u re . r ece i ve s em  --  the  returned  receive  semaphore. 

*/ 

iii.  dynamicmachinepath 


dynami  cmach i nepa  t  h( segment  num.mname , sendpor  t  num. receivepor  t num, server, 
instructure, freespace) 


long  segmentnum;  /*  the  key  to  use  for  the  created  shared  segment  */ 
char  mname]];  /*  machinename  character  string  */ 

long  sendpor t num,  rece i vepo r t num;  /*  send  and  receive  port  numbers  */ 
char  server]];  /*  this  character  string  is  either  "client"  or  "server 
It  indicates  whether  the  s ende r / r ece i ve r  should  open 
up  as  either  s  client  or  server.  The  first  guy  open 
must  be  the  server  . 


Machine 


*/ 

* i n s t rue t u re ;  /*  structure  to  hold  segment  and  semaphore  info: 

char  * i n s t rue t u re . segmen f  --  returned  ptr  to  the  shared  segment, 
int  ins t rue t u re . shmi d  --  returned  system  generated  shared  mem  id 
int  i ns t r uc t u r e . send  a em  --  the  returned  send  semaphore. 

We  base  it  rn  the  send  portnumber. 
int  i n s t rue t u re . r ece : sc sem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 


*/ 


int  freespace;  /*  amount  of  freespace  desired  for  dynamic  memory  allocation 
after  this  routine  has  been  called.  */ 
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iv.  dynamicmachinepaths 

dyr  ami  cmach i nepa  t  hs ( nurrmach i ne  s , segmen  t  num.mname  ,  Bendpor t  num,  receiveportnum, 
se rve r , i n s t rue t u re , f ree space ) 


int  nurrmach i ne s ;  /*  the  maximum  number  of  other  machines  to  be  attached  */ 
long  segmentnum;  /*  the  key  to  uae  for  the  created  shared  segment  */ 
char  mname[];  /*  machinename  character  string  */ 

long  sendpo r t num,  rece i vepor t num;  /*  send  and  receive  port  numbers  */ 
char  server[];  /♦  this  character  string  is  either  "client"  or  "server". 

It  indicates  whether  the  sende r / rece i ve r  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
mus  t  be  the  server. 


Mach  i  ne 


*/ 

* i n s t r uc t u r e ;  /*  structure  to  hold  segment  and  semaphore  info: 

char  * i n s t rue t u re  .  se gmen t  --  returned  ptr  to  the  shared  segment, 
int  i n s t r uc t ur e . shmi d  --  returned  system  generated  shared  mem  id 
int  i u s t rue t ure . sends em  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portn  umb  e  r  . 
int  ins t rue t u i e . r ece i ve s em  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 


*/ 


int  freespace;  /*  amount  of  freespace  desired  for  dynamic  memory  allocation 
after  this  routine  has  been  called.  */ 


b.  Code  and  Description 


TITLE  In t er -Compu t e r  Contnun  i  c  a  t  i  on  Package 
tvUAJLE  :  mpath.c 


VERSION:  5.0 

DATE  :  31  May  1988 

AUTHOR  :  Theodore  H.  Barrow 


HISTORY: 

VERSION 

DATE 

AUTHOR 

DESC. 

VERSION 

DATE 

AUTHOR 

DESC. 

VERSION 

DATE 

AUTHOR 


1.0 

6  February  1987 
Mi  chae I  J .  Zyda 

Contains  routines  machinepath  and  de 1 e I emach i nepa t h  for 
link  c i e a t i on/ remova 1  at  a  high  level  of  abstraction. 

2.0 

27  May  1987 
Theodore  H.  Barrow 

Converted  to  use  a  structure  for  ease  of  use. 

3.0 

21  Oc  t  obe  r  1987 
Theodore  H  Barrow 

Added  function  dynami  cmach i nepa t h  to  allow  dynamic  memory 


DESC 
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allocation  after  conmunicat ion*  link  established. 


VERSION: 

4.0 

* 

* 

* 

DATE 

15  December  1987 

* 

♦ 

AUTHOR  : 

Theodore  H.  Barrow 

♦ 

* 

DESC. 

Added  function  dynamicmachinepath*  to  allow  use  with  multiple  * 
links.  Modified  all  creation  routines  to  place  sequence  * 
numbers  at  end  of  conmand  line  for  send  and  receive  processes.* 

VERSION: 

5.0 

DATE 

31  May  1988 

AUTHOR  : 

Theodore  H.  Barrow 

**** 

DESC. 

Added  broadcast  and  receive  capabil 

ity  -  one  process  spawned  * 

RECORD  OF  CHANGES 

*Ver 
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* 
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*  Affected  *Reqd* 

*  Modules  *Vers* 
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♦  ♦ 

♦  *  * 

♦  *  * 
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#include  "shared. h"  /*  my  special  defines  */ 

# i nc 1 ude  <g 1 . h> 

de 1 e  t emach i nepath( instructure) 

Machine  * i n s t rue t u re  ;  /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue t ure . segment  --  returned  ptr  to  the  shared  segment. 

int  ins t rue t ure . shmi d  --  returned  system  generated  shared  mem  id 

int  ins t rue t ure . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 

int  i n s t rue t u re . rece i ve sem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 


*/ 


I 


/*  kill  the  receiver  process...  */ 

kill_receiver(instruc  t ure->segmen t , ins  t  rue  t u  re ->r ece i ve  sem)  ; 
/*  kill  the  sender  process...  */ 

kill_sender(instruct  u  r e ->s  egmen  t.injtructure - >s  end  sem) ; 

/*  detach  and  delete  the  shared  segmen* . . .  */ 

dele  tesha  reds egmen  t( in structure  - >s egmen t , instructure ->shmi  d ) ; 
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/* 

For  direct  connection,  both  send  and  receive  processes  are  apawned. 

For  broadcast,  either  send  or  receive  process  is  spawned. 

The  machinepath  routine  performs  the  following: 

(1)  creates  a  shared  segment. 

(2)  creates  a  send  and/or  receive  semaphore  based  on  the  send  and  receive 
port  numbers. 

(3)  f ree_sende r ( segmen t )  and/or  f ree_rece i ve r ( legmen t ) 

(4)  spawns  off  the  send  and/or  receive  processes. 

system("send  sharedseg#  machinename  port#  se r ver /c 1 i en t /broadc as t  0&" ) ; 
sy s tem(  " rece  i  ve  sharedseg#  machinename  port#  server/client/receive  04"  ) ; 

(5)  the  send  and  receive  semaphores,  the  pointer  to  the  shared  segment, 
and  the  id  of  the  shared  segment  are  placed  in  a  structure  of  type 
Machine  that  is  declared  in  the  calling  program. 

*/ 

machi nepa t  h( segmen tnum.mname  , sendpor  t num,  rece i vepor  t num,  server, instructure) 


long  segmentnum;  /*  the  key  to  use  for  the  created  shared  segment  ♦/ 
char  mname[];  /*  machinename  character  string  */ 

long  sendpor t num,  rece i vepor t num;  /*  send  and  receive  port  numbers  */ 

char  server[l  /*  this  character  string  is  either  "client",  "server", 

"broadcast",  or  "receive”.  If  direct  connection  wanted, 
it  indicates  whether  the  s ende r / r ece i ve i  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server.  If  broadcast  wanted,  it  indicates 
whether  to  open  up  as  broadcaster  or  receiver. 

*/ 

Machine  *  i  n s t rue t ure ;  /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue t ure . segmen t  --  returned  ptr  to  the  shared  segment, 
int  inst ructure. shmid  --  returned  system  generated  shared  mem  id 

int  ins t rue t ure . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 


I 


int  i n a t r uc t u r e . rece i ve sem  --  the  returned  receive  semaphore. 
*/ 

char  *sharedsegment ( ) ;  /*  shared  segment  creation  function  */ 


int  semt  ran(  )  ; 


/*  semaphore  creating  routine.  */ 


char  lemp[200),  temp2[200];  /*  temp  character  arrays  */ 


/*  create  the  shared  segment  */ 

instructure  -  >  segmen  t  =  s  ha  r  ed  segmen  t  f  segmen  t  n  um  .MAXSHAREDS I ZE ,  St.  i  n  s  t  r  uc  t  u  re  ->shmi  d )  ; 

/*  create  the  send  semaphore,  (unused  if  receiving  broadcast  messages)  */ 
inst ructure->sendsem  =  semt  r an ( sendpor t num) ; 

/*  create  the  receive  semaphore  (unused  if  broadcasting  messages)  */ 
i n s I  rue i ur e ->rece i ve sem  -  s emt  r an ( rec e i vepor t num)  ; 

/*  free  the  sender  and  receiver  parts  of  the  shared  segment  */ 
i n i t _sha red_bu ffer( inst  ructure - >segmen t ) ; 

/*  spawn  off  the  sender  process  */ 

i f (  s  t  r emp (  server,  "receive"  )  !  =  0  ) 

( 
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/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 

■  I  rcpy  (  t  emp ,  SEJOLOCATICN) ; 
s t rca t ( temp, "  "); 

/*  add  the  number  of  the  sharedsegment  in  text  */ 
spr in  t  f ( t  emp 2 ,  "%d" , ins  t  rue  t ure ->snmi  d ) ; 
s  t  rc  a  t ( t  emp , t  emp 2 ) ; 
a t rca t ( t emp, "  ") ; 

/*  add  on  the  machine  name  */ 
s  t  rca  t  ( t  emp.mname  ) ; 
s  t  r  c  a  t  (  t  emp  , "  " ) ; 

/*  add  the  port  number  */ 
sprintfft  emp 2 , "%d ” , sendpor  tnum)  ; 
st  rca t ( temp, t emp 2 ) ; 
s  t  i  c  a  t  (  t emp , "  "  ) ; 

/*  indicate  whether  a  server,  a  client,  or  a  broadcaster  */ 
s  t  rca  t ( t  emp  .server); 
s  t  r  c  a  t ( t  emp , "  0  "  ) ; 

/*  spawn  off  into  the  background  */ 
s  t  rca  t ( temp, "A" ) ; 

/*  spawn  off  the  sender  */ 
iff  system(temp)  ==  -1  ) 

pe r ror ( " SEhO  system  call  failed"); 

I 

else 

( 

/*  kill  sender  (which  really  doesn’t  exist  anyway)  so  that  the 
sender_i s_f ree( )  call  will  always  return  FALSE. 

A  similar  thing  does  not  have  to  be  done  for  rece i ve r_ha s_da t a ( 
in  a  broadcasting  path  since  it  will  always  return  PALSE  anyway 
kill_sender(  ins t rue ture->segment  ,  i n s t rue t ure ->sendsem  ); 

I 


/*  spawn  off  the  receiver  process  ♦/ 

if(  strcmp(  server,  "broadcast”  )  !=  0  ) 

( 

/•  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
s  t  rcpy  (  t  emp.RECEIVELOCATICN)  ; 
s  t  r  c  a  t ( t emp , "  " ) ; 

I*  add  the  number  of  the  sharedsegment  in  text  */ 
spr in t  f ( t  emp 2 ,  "%d" , ins  t  rue  tu  re ->shmi d) ; 
s  t  rca  t ( temp, t  emp 2 ) ; 
s  t  r  c  a  t ( t  emp , "  " ) ; 

/*  add  on  the  machine  name  */ 
s  t  rca  t  ( t  emp.mname  )  ; 
s  t  rca  t ( t  emp , "  " ) ; 

/*  add  the  port  number  */ 

*pr i n  t  f ( t  emp 2 , "%d” .receiveport  num)  ; 
s  t  rc  a  t  ( t  emp ,  t  enip2 ) ; 
s  t  rca t ( t  emp , ”  " ) ; 

/*  indicate  whether  a  server,  a  client,  or  a  broadcast  receiver  */ 
s  t  rca  t ( t  emp .server); 
s  t  rca  t ( t  emp, "  0" )  ; 

/*  spawn  off  into  the  background  */ 
s  t  rc  a  t ( t  emp , "A"  ) ; 
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/*  spawn  off  the  receiver  •/ 
i f (  s  y  « t  em( t  emp )  ■—  - 1  ) 

perror( "RBCbIVB  ays  fern  c» 


system  cell  failed"); 
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For  direct  connection,  both  tend  and  receive  procettes  are  spawned. 

For  broadcast,  either  send  or  receive  process  is  spawned. 

The  dynamicmachinepath  routine  performs  the  following: 

(1)  creates  a  shared  segment  and  attaches  it  to  the  main  program  virtual 
space  after  an  allocation  of  free  memory  space. 

(2)  creates  a  send  and/or  receive  semaphore  based  on  the  send  and  receive 
port  numbe r s  . 

(3)  f ree_sende r ( segmen t  )  and/or  f r ee_r ece i ve r ( segmen t ) 

(4)  spawns  off  the  send  and/or  receive  processes. 

sy s t em(  " send  sharedseg#  machinename  port#  se r ve r /c 1 i en t /broadca s t  0&"  ) ; 
sy s t em(  " rece i ve  sharedseg#  machinename  port#  se r ve r /c 1 i en t / r ece i ve  0&”  ) 
(3)  the  send  and  receive  semaphores,  the  pointer  to  the  shared  segment, 
and  the  id  of  the  shared  segment  are  placed  in  a  structure  of  type 
Machine  that  is  declared  in  the  calling  program. 


dynami  cmach i nepa  t  h( segmen  tnum.mname  , sendpor  tnum,  rece i vepor  tnum,  server, 
ms!  r'icture, freespace) 


long  segmentnum;  /*  the  key  to  use  for  the  created  shared  segment  */ 
char  mname ( ) ;  /*  machinename  character  string  */ 

long  sendpor t num,  rece i vepor t num;  /*  send  and  receive  port  numbers  */ 

char  server[];  /*  this  character  string  is  either  "client",  "server", 

"broadcast",  or  "receive".  If  direct  connection  wanted, 
it  indicates  whether  the  sende r / rece i ve r  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server.  If  broadcast  wanted,  it  indicates 
whether  to  open  up  as  broadcaster  or  receiver. 

*/ 


Machine  *  i  n s t rue t u re ;  /*  structure  to  hold  segment  and  semaphore  info; 

char  *  ins t rue t ure  .  segmen t  --  returned  ptr  to  the  shared  segment. 

int  ins t rue t ure . slunid  --  returned  system  generated  shared  mem  id 

int  ins t rue t ure . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 

int  ins t rue t ure . rece i vesem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber 


*/ 

int  freespace;  /*  amount  of  freespace  desired  for  dynamic  memory  allocation 

after  this  loutine  has  been  called.  * / 


char  *dynami c sha redsegmen t (  )  ; 

int  semt  ran(  )  ; 

char  temp [200],  temp2[200j. 


I*  shared  segment  creation  function  */ 
/*  semaphore  creating  routine.  */ 

/  *  t  etr.p  character  arrays  *  / 


/*  create  the  shared  segment  */ 

i n s t r uc t u r e ->se gmen t  =  dynami c sha reds e gmen t ( 1 , s egmen t num,  MAXSFWREDS I ZE , 

<ftinstructure - >shmi d, freespace); 

/*  create  the  send  semaphore,  (unused  if  receiving  broadcast  messages)  */ 
i ns t rue t ure ->sendsem  =  semt r an ( sendpor t num)  ; 

/♦  create  the  receive  semaphore  (unused  if  broadcasting  messages)  */ 
inst ructure->receivesem  =  semt  ran(  rec- :  *'epor  t  num)  ; 


i 
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/*  free  the  tender  end  receiver  pertt  of  the  shared  segment  */ 
ini t_shared_buf fer( i ns t rue t u re ->segmen t ) ; 

/*  spawn  off  the  sender  process  */ 

if(  ttrcmp(  server,  "receive"  )  l«  0  ) 

( 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
st  rcpy(  t  emp ,  SEMXjOCATICH)  ; 
street (temp,"  "  ) ; 

/*  add  the  number  of  the  sharedsegment  in  text  */ 
sprintf( t  emp 2 ,  "%d" , ins  t  rue  ture ->snmi d) ; 
s  t  rc a  t  (  t  emp ,  t  emp 2 ) ; 
s t real ( t emp, "  ")  ; 

/*  add  on  the  machine  name  */ 
s  t  rc  a  t  ( t  emp  ,mname ) ; 
s t rca t ( t emp , "  "); 

/*  add  the  port  number  *J 
spr int  f ( t  emp 2 , "%d" , sendpor  tnum) ; 
s  t  rc  a  t ( t  emp , t  emp 2 ) ; 
s  t  rca  t  ( temp,  "  " )  ; 


/*  indicate  whether  a 
s  t  rca  t ( temp, server ) ; 
s t rcat ( temp, "  0&" ) ; 


server,  a  client,  or  a  broadcaster  ♦/ 


/*  spawn  off  the  sender  into  the  background  */ 
i f (  s  y  s  t em(  t  emp )  ==  - 1  ) 

perror(”SEft)  system  call  failed"); 


else 

1 


/ 


kill  sender  (which  really  doesn’t  exist  anyway)  so  that  the 
sender_i s_f ree( )  call  will  always  return  FALSE. 

A  similar  thing  does  not  have  to  be  done  for  recei ver_has_data( ) 
in  a  broadcasting  path  since  it  will  always  return  FALSE  anyway  •/ 
kill_sender(  in s t rue t u re ->segraenf ,  ins t r uc t u r e ->send» em  ); 


/*  spawn  off  the  receiver  process  */ 


if(  strcmp(  server,  "broadcast”  )  !=  0  ) 


( 


/*  add  the  start  of  the  line, 
s  t  rcpy(  temp.RECEIVELOCATICN)  ; 
s  t  r  c  a  t ( t emp , "  " ) ; 


the  program  to  run  */ 


/*  add  the  number  of  the  sha redsegmen t  in  text  */ 
spr in t  f ( t  emp2 ,  "%d" , ins  t  rue  t u re ->s nmi d ) ; 
st  rcat ( temp, temp2) ; 
s  t  rcat ( temp, "  " ) ; 


/*  add  on  the  machine  name  */ 
s  t  rcat  (  t  emp, inname  ) ; 
s treat ( temp, "  ") ; 


/*  add  the  port  number  */ 

spr in t  f ( t  emp 2 ,  "%d” , r ece i vepo r  t num) ; 

s  t  rca t ( t  emp, t  emp2 ) ; 

s t  rcat ( t emp, "  " ) ; 


/*  indicate  whether  a  server, 
s  I  rca t ( t  emp  .server); 
st rcat ( temp, "  0*”); 


a  client,  or  a  broadcast  receiver  */ 
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/• 

For  direct  connection,  both  send  and  receive  processes  are  spawned. 

For  broadcast,  either  send  or  receive  process  is  spawned. 

The  dynamicmachinepaths  routine  performs  the  following: 

(1)  creates  a  shared  segment  large  enough  for  multiple  attachments 

and  attaches  it  to  the  main  program  virtual  space  after  an  allocation 
of  free  memory  space. 

(2)  creates  a  send  and/or  receive  semaphore  based  on  the  send  and  receive 
port  numbers. 

(3)  f ree_sender( segment )  and/or  f ree_receiver( segment ) 

(4)  spawns  off  the  send  and/or  receive  processes. 

system("aend  sha redseg#  machi nename  port#  se rve r /c 1 i en t /broadcas t  0&"  ) ; 
sy s t em(  ” rece i ve  sharedseg#  machi nename  port#  se rve r /c I i en t / rece i ve  0&”  )  ; 

(5)  the  send  and  receive  semaphores,  the  pointer  to  the  shared  segment, 
and  the  id  of  the  shared  segment  are  placed  in  a  structure  of  type 
Machine  that  is  declared  in  the  calling  program. 

*/ 

dynami  cmach i nepa  t  hs (nuirmach i ne s , s igmen t num.mname , sendpor  tnum, rece i vepor  tnum, 
server, instructure, f  r ee apace ) 

int  nunmach i ne s ;  /*  the  maximum  number  of  other  machines  to  be  attached  */ 
long  segmentnum;  /*  the  key  to  use  for  the  created  shared  segment  */ 
char  mname[];  /*  machinename  character  string  */ 

long  sendportnum,  recei vepor tnum;  /*  send  and  receive  port  numbers  */ 

char  serverfj;  /*  this  character  string  is  either  "client”,  "server", 

"broadcast",  or  "receive".  If  direct  connection  wanted, 
it  indicates  whether  the  sender/receiver  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server.  If  broadcast  wanted,  it  indicates 
whether  to  open  up  as  broadcaster  or  receiver. 

•/ 


Machine  *  ins t rue t ure ;  /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue ture . segment  --  returned  ptr  to  the  shared  segment. 

int  ins t rue ture . shmid  •-  returned  system  generated  shared  mem  id 

int  inst ructure. sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 


int 


instructure. receivesem 

*/ 


--  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 


int  freespace; 

I 


/♦  amount  of  freespace  desired  for  dynamic  memory  allocation 
after  this  routine  has  been  called.  */ 


char  *dynami c sharedsegment ( ) ; 

int  semtran(); 

char  temp[200],  temp2[200]; 

static  Boolean  firsttime  =  TRUE; 

static  int  sequencenum  =  0; 

static  int  totmachines; 

/*  check  for  first  time  called  a 
i f (  f i r  s  1 1 ime  ) 


/*  shared  segment  creation  function 
/*  semaphore  creating  routine.  */ 

/*  temp  character  arrays  */ 

/♦  flag  to  detect  multiple  requests 
/*  sequence  number  for  receive/send 
/*  max  attachments  permitted  */ 
d  establish  max  possible  attachments 


*/ 


•/ 

*/ 

*/ 
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i 


totmachines  =  nimmacbines 
f i r  *  1 1  ime  =  FALSE ; 


el  a e 

++ sequence nun; 


/*  check  for  violation  of  maximum  attachment!  */ 
if(  sequencenum  >*  totmachinei  ) 

pe r ror ( "mpa t h :  Too  many  attachmenta  attempted”); 
exi t(  -1  ); 


/*  create  the  shared  segment  */ 

i ns t rue t ure ->segmen t  »  dynamic shared seamen t (niwmach ines , segmen t num, 

MAXSHAFEDSIZE, 

Aina  t  rue  tore ->shmid, free space ) ; 


/♦  create  the  send  semaphore,  (unused  if  receiving  broadcast  messages)  */ 
i n s t rue t ure ->sendsem  =  semt  ran( sendpor tnum) ; 

/*  create  the  receive  semaphore  (unused  if  broadcasting  messages)  */ 
i ns t rue t ur e ->r ece i ve sem  *  semt ran( rece ivepor t num) ; 


/*  free  the  sender  and  receiver  parts  of  the  shared  segment  */ 
ini t_shared_buf f er ( instructure->aegment) ; 


t*  spawn  off  the  sender  process  */ 
if(  strcmp(  server,  "receive"  )  !=  0  ) 

I 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
s  t  rcpy(  temp.SEMXjOCATIGN) ; 
s  t  rcat  (  temp,  ”  "); 

/*  add  the  number  of  the  sha redsegmen t  in  text  *f 
spr int  f ( t  emp2 ,  "%d" , ins  t  rue  ture->snmid) ; 
s  t  rc a  t  (  t  emp ,  t  emp2 ) ; 
at  rest ( temp, "  " ) ; 


/*  add  on  the  machine  name  */ 
s  t  rca  t  ( t  emp.mname  ) ; 
strcat( temp, "  "); 

/*  add  the  port  number  */ 
sprint f( temp2,"%d" , sendpor t num) ; 
s  t  r c  a  t ( t emp , t  emp  2 ) ; 
s  t  rca t ( temp, "  " ) ; 

/*  indicate  whether  a  server,  a  client,  or  a  broadcaster  */ 
s  t  rca  t ( t  emp, server ) ; 
s  t  rcat ( temp, "  "); 

/*  add  the  machine  sequence  number  */ 
spr in t  f ( t  emp 2 ,  ”%d" , sequencenum) ; 
s  t  rca t ( temp, t  emp 2 ) ; 

/♦  spawn  off  into  the  background  */ 
s  t  rcat ( temp, "A"  ) ; 

/*  spawn  off  the  sender  */ 
i  f (  s  y  s  t  em( t  emp )  =*  - 1  ) 

perror( "SEbO  system  call  failed"); 

I 

el  se 

( 

/*  kill  sender  (which  really  doesn’t  exist  anyway)  so  that  the 


inrYWirani  \ni  \ni  wwa^w wjwtv  wrv.itn 


mpath.c 


sender_i s_f ree( )  call  will  always  ret’irn  FALSE. 

A  similar  thin|  does  not  have  to  be  done  for  receiver_has_data( ) 
in  a  broadcasting  path  since  it  will  always  return  FALSE  anyway  */ 
kill_sender(  ins t rue t ure ->segmen t ,  ins t rue t ure ->sendsem  ); 


/*  spawn  off  the  receiver  process  */ 


iff  strempf  server,  "broadcast"  )  1=  0  ) 


I*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
st  rcpy(  temp.RECEIVELOCATICN) ; 
s t re at ( temp, "  "); 


/*  add  the  number  of  the  sharedsegment  i 
spr in t  f ( t  emp  2 ,  "9fcd" , ins  t  rue  ture->shmid) ; 
s  t  re  a  t ( t  emp , t  emp2 ) ; 
s  I  r  c  a  t ( t  emp , "  " ) ; 


/*  add  on  the  machine  name  */ 
s  t  rca  t  (  t  emp ,mname ) ; 
s t re a t ( t emp, "  "); 


/*  add  the  port  number  */ 

spr in  t  f ( t emp 2 , "%d" , rece i vepor  tnum) ; 

s  t  r  c  a  t ( t  emp , t  emp 2 ) ; 

s t rca t ( t emp, ”  "); 


/*  indicate  whether  a  server,  a  client,  or  a  broadcast  receiver  */ 
s  t  real ( t  emp, server ) ; 
s t rca t ( t emp, "  "); 


/*  add  the  machine  sequence  number  */ 
spr in t  f ( t  emp 2 ,  "%d" , sequence num)  ; 
s  t  rc a  t ( t  emp , t  emp 2 ) ; 


/*  spawn  off  into  the  background  */ 
s  t  rca t ( t  emp, ) ; 


/ *  spawn  off  the  receiver  *  / 


i  f  (  s  y  a  t  em(  t  emp )  ==»  - 1  ) 

perrorC'RECEIVE  Systran  call  failed"); 


3.  netV.c 


a.  Calling  Protocols 

This  module  contains  the  low-level  socket-managing  calls.  No  functions  in 
this  module  are  intended  for  application  programs.  This  module  is  only  linked  into  the 


send  and  receive  processes. 
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AUTHOR  :  Theodore  H.  Barrow 


DESC.  :  Added  ■ t ar t _broadca a t ( )  and  broadcaat_receive( )  to  provide 
datagram  socket*  for  broadcast  use.  These  sockets  use  the 
default  Internet  broadcast  addressing. 
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/* 

This  segment,  when  linked  into  a  program  on  a  computer  with  a  UNIX  4.2  BSD 
operating  system,  will  allow  the  program  to  comnunicate  with  programs 
executing  on  other  computer  systems  over  an  Internet  network. 

*/ 

♦define  TRUE  1 

/*  include  files  for  UNIX  4.2  BSD.  These  are  all  called  from  the  bad 

subdirectory  in  /us r/ inc lude .  The  file  svs/types.h  also  exists  and  is 
included  when  bsd/sy s/ t ypea . h  is  used.  This  was  done  for  ease  of  change 
if  and  when  Silicon  Graphics  changes  the  include  library  structure.  */ 
♦include  <sy s / t ype s . h> 

♦include  <sys/ socke t . h> 

♦include  <bsd/ne t i ne t / i n . h> 

♦include  <bsd/ne t db . h> 

y********************************* . a*...*********. ******* 

The  connect_server( remote_cI ient_name ,  port^number)  function  performs 
the  actions  required  to  connect  a  server  system  to  a  remote  client  system 

,•**•.***,**•*******•*••**,,*,*****••••*. a****,**,**, ♦***•**/ 


int  connect_server(remote_cI ient_name  ,  port_number) 

char  refflo t e_c 1 ient_name [ ] ;  /•  name  of  the  remote  client  system  */ 

int  port_number;  /*  port  number  to  the  remote  client  system  */ 

I 

char  *pt r_c 1 ient_name ;  /*  pointer  to  the  remote  client  system's  name  */ 

int  local_server_socket  ;  /*  local  socket  number  */ 

int  socket!);  /*  function  that  opens  a  socket  */ 

int  accept!);  /*  function  that  accepts  a  connection  from 

a  remote  client  socket  •/ 

int  remot e_c 1 i en t_socke t  =  -1;  /*  socket  number  of  remote  client  system  */ 

/*  protocol  and  address  data  structure  for  socket  */ 
static  struct  sockaddr_in  address  =  {  AF_ 1NET  ); 

long  remot e_c 1 i en t_addres s ;  /*  address  of  the  remote  client  system  */ 

short  remo t e_c 1 i en t _por t ;  /*  port  number  of  the  remote  client  system  */ 

int  addres s_s i ze ;  /*  size  of  address  of  remote  client  system  */ 


/*  create  socket  structure  from  input  parameters  */ 

/*  get  a  pointer  to  the  remote  client  system’s  name  */ 
pt r_c 1 ient  name  *  remot e_c 1 i en t_name  ; 

/*  convert  the  remote  client  system  name  to  its  address. 

Note  that  gethostbyname!  )  requires  a  pointer  to  a  pointer  •/ 
remote_c 1 ient_addresa  =  ! 1 ong )ge t hoi t byname  i&p t r_c 1 i en t _name  ) ; 

/*  set  the  remote  client  port  number  above  the  system  reserved  ports 

by  adding  the  remote  client  port  number  to  the  number  of  reserved  ports  */ 
remote_cl ient_port  =  I PPORT_RESERVED  +  porl_number; 

/*  remote  client  system  address  family  (Internet  in  this  case)  */ 
addre ss . s i n_f ami  1 y  =  AF_INET  ; 
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t*  place  the  remote  client  port  number  into  the  address  data  structure 
in  network  byte  order  */ 
address . s in_por t  =  h t ons ( remo  t e_c 1 i en t _po r t ) ; 

/*  place  the  remote  client  system's  address  in  the  address  data  structure  */ 
address . s in_addr . s_addr  -  r emo t e_c 1 i en t _addr e s s ; 

/*  find  number  of  bytes  in  the  remote  client  address  */ 
address_size  =  s  i  zeof ( remo  t e_c 1 i en t _addr e s s ) ; 

/*  attempt  to  open  a  local  socket  */ 
local_server_socket  =  socke  t  (AF_ INET, SOCK_STREAM,  0) ; 

i  f (  1  oc a l_se r ve r_socke t  <  0) 

perror( "Server  couldn't  open  a  local  socket:"); 
else 

I 

i f (bi nd( 1  oca l_se r ver_socke t ,  ( c addr_t )&addre s s ,  s  i zeof ( addre s s  ) )  <  0) 
perror("Server  couldn't  bind  address  to  local  socket:"); 

/*  set  the  maximum  number  of  remote  client  systems  to  be  connected  to  */ 
listen(l°cal_server_socket, SCM\XC0NN) ; 

p r  i  n t f ( "Se r ve r  waiting  to  connect  to  %s \n” , remo t e_c 1 i en t _name ) ; 

/*  attempt  to  accept  a  connection  */ 

r emo t e_c 1 i en t _socke t  =  accep t ( 1 oc a  1 _s e rve r_socke t ,  &address, 

&addr  e  s s_s i ze  )  ; 

if(remote  c 1 i en t _ s ocke t  <  0) 

I 

/*  an  error  occurred  in  the  server  attempting  to 
accept  a  connection  from  remote  client  system  */ 
pe r ro r ( *'Se r ve r  couldn't  accept  connection  from  remote  client  system:"); 

s hut  down  ( local_server_socket,  2); 
close(local  se r ve r_socke t ) ; 

I 

/*  else  the  server  accepted  a  connection  from  the  remote  client  system  */ 


/*  return  the  socket  number  of  the  remote  client  system  */ 
return! remo  t  e_c 1 ient_sockei )  ; 

*  i  nnect_server  */ 


’■*  *>•  •*»■*»*  *  ' 
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The  connect  c 1 i en t ( remot e_»e r ve r_name ,  port_number)  function  perform! 
all  the  actions  requited  To  connect  a  client  system  to  a  remote  server 
system 


/ 


int  connec t_c 1 i en t ( remot e_se rve r_name ,  port_number) 


char  r emo t e_se r ve r_name  [  ] ; 
int  port_number; 

int  local_cl ient_socket ; 
int  socket ( ) ; 


/*  name  of  the  remote  server  system  */ 

/*  port  number  to  the  remote  server  system  */ 

/*  local  socket  number  */ 

/*  function  that  opens  a  socket  */ 


/*  function  that  connects  local  socket  to  remote  server  socket  */ 
int  connect (  ) ; 


int  remote_server_socket ; 


/*  socket  number  on  remote  server  system  */ 


/*  the  protocol  and  address  data  s t rue t u re  spec i f i ed  for  the  socket  */ 
static  struct  sockaddr_in  address  =  (  AF_INET  ); 

struct  hostent  * remot e_se rve r_addre s s ;  /*  address  of  remote  server  system  */ 
short  r emo  t e_se rve r_por t ;  /*  port  number  of  remote  system  */ 


/*  create  socket  structure  from  input  parameters  */ 


/*  convert  the  remote  server  system  name  to  its  address. 

Note  that  ge t hoa t byname (  )  requires  a  pointer  only  in  this  case  */ 
remot  e_server_address  m  ge t hos t byname ( remot e_se rve r_name )  ; 

/*  clear  out  the  address  structure  */ 
bzero((char  *)&address,  s i zeof ( addre s s ) ) ; 

/*  copy  the  remote  server  address  structure  into  the  address  structure  */ 
bcopy ( remot  e_server_address->h_addr , 

(char  * )&addre s a . s i n_add r , 
r  emo t  e_se  rve  r_addr e  s  s->h_length); 

/*  set  remote  server  port  number  above  the  system  reserved  ports  by  adding 
the  user’s  remote  server  port  number  to  the  number  of  reserved  ports  */ 
r  emo t e_s e r ve r_po r t  =  IPPORT_RESERVED  +  port_number; 

/*  remote  server  system  address  f ami  1 y (  In t e rne t  in  this  case)  */ 
add r e s s . s i n_f ami  1 y  =  AF_1NET; 

/*  place  the  remote  server  port  number  into  the  address  structure 
in  network  byte  order  */ 
addre ss . s i n_por t  =  h t ons ( r emot e_se r ve r _po r t ) ; 

/*  attempt  to  obtain  a  local  socket  */ 

I oc a  1 — c 1 1 en t ^socke t  =  socke  t (AF_INkT.  SOCIC_STRHAM,  0); 

i f (  1  oc a l_c 1 i en t _socke t  <  0) 

pe r ror ( "Cl i en t  couldn’t  open  a  local  socket:"); 
e  1  ss 

/*  place  Internet  address  family  type  in  address  structure  */ 
address . sin_f  ami ly  =  AF_ 1NET ; 
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/*  attempt  to  connect  local  client  aocket  to  remote  server  socket  */ 
retno t e_se rve r_socke t  *  connect ( iocal_cl ient_socket ,  (caddr_t )&address  , 

sizeof (address) ) ; 


i f ( remote_server_socket  <  0) 

( 

/*  error  occurred  in  attempting  to  connect  to  remote  server  socket  */ 
perror( "Cl ient  couldn’t  connect  to  the  remote  server  socket:"); 

shutdown! Iocal_c 1 ient_socket ,  2); 
close( local_cl ient_socket ) ; 

I*  set  local_cl ient_socket  so  that  negative  value  is 
always  returned  when  an  error  occurs 

*/ 

local_client  socket  =  remote  server  socket; 

) 

else 

/*  successfully  connected  to  the  remote  server  system  */ 

pr i n t f ( "Connec t i on  established  with  %s . \n" , remot e_se rve rename ) ; 


I 

/*  return  the  socket  number  of  the  local  client  system  */ 
return(local_clien!_socket); 

/*  connect_c 1 ient  */ 
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The  start_broadcast(port_number)  function  performs 

the  actions  required  to  initiate  a  datagram  broadcast  socket 


int  s t a r t _b roadc a s t (por t _numbe r ) 


int  por t_number ; 


int  broadcast  socket 


int  socket(); 
int  se  t  sockopt ( ) ; 
int  on  =  TRUE; 


/*  port  number  for  the  remote  receiver  system  */ 


/*  local  socket  number  */ 

/*  function  that  opens  a  socket  */ 

/*  function  that  sets  a  socket  to  allow  broadcast  */ 
/*  to  set  broadcast  toggle  on  for  socket  */ 


/*  protocol  and  address  data  structure  for  socket  */ 
static  struct  sockaddr_in  address  =  (  AF_INET  ); 


short  broadcas t_por t ; 


/*  port  number  broadcast  heard  from  */ 


/*  create  local  socket  structure  from  input  parameters  */ 

/*  set  the  broadcast  port  number  above  the  system  reserved  ports 

by  adding  the  broadcast  port  number  to  the  number  of  reserved  ports  */ 
broadcas t_por t  *  IPPORT_RESERVED  +  port_number; 

/*  system  address  family  (Internet  in  this  case)  */ 
address . sin_fami ly  *  AF_ I NET  ; 

/*  place  the  port  number  into  the  address  data  structure 
in  network  byte  order  */ 
address . sin_port  =  h t on s (b r oadc a s t _por t ) ; 

/*  place  the  local  address  in  the  address  data  structure 
in  network  byte  order  •/ 
address . sin_addr . s_addr  =  h t on  1 ( INAECR_ANY) ; 

/*  attempt  to  open  a  local  socket  */ 
broadcast  socket  =  socke  t  ( AF_1NKI' ,  S  OCXDGRAM ,  0) ; 

i  f ( broadc as t _socke t  <  0) 

perror( "Broadcaster  couldn't  open  a  local  socket:"); 
e  1  se 
( 

/*  set  the  broadcast_socket  for  broadcasting  */ 
i f ( se t sockopt (  broadcas t_socket ,  SOL_SOCXfcl ,  SO_BRQADCAST , 

Aon,  sizeof(on)  )  <  0) 

pe r ro r ( "Broadc a s t e r  couldn't  set  socket  to  broadcast:”); 

else  if(bind(  broadca s t _socke t ,  (struct  sockaddr  *)Aaddress, 
s i zeof ( add  re s s )  )  <  0) 

per ror ( "Broadcas t er  couldn't  bind  to  local  socket:"); 
e  I  se 
( 

pr  i  n t f (  "Wa i t  i  ng  to  broadcast\n" ) ; 

I 

) 

/*  return  the  socket  number  * / 
return(broadcast_socket  ) ; 

)  /*  s t a r t _broadc as t  */ 
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. . . . ******** 

The  broadcast_receive(broadcaster_naroe .port.number)  function  performs 
all  the  actions  required  to  set  up  a  broadcast  receiving  socket 


int  broadcas  t_recei ve( broadens t er_name , por  t .number ) 

char  broadcas ter_name[ ] ;  /*  name  of  the  broadcaster  system  */ 

int  port.number;  /*  port  number  for  the  broadcaster  */ 


int  local.socket;  /*  local  socket  number  */ 

int  socket();  /*  function  that  opens  a  socket  */ 

int  broadcaster.socket ;  /*  socket  number  on  broadcaster  system  */ 

/*  the  protocol  and  address  data  structure  specified  for  the  socket  */ 
static  struct  sockaddr.in  address  =  {  AF.INOT  ) ; 

struct  hostent  *broadcas ter. address ;  /*  address  of  broadcaster  system  */ 
short  broadcaster.port  ;  /*  port  number  of  remote  system  */ 


/*  create  socket  structure  from  input  parameters  */ 


/*  convert  the  broadcaster  system  name  to  its  address. 

Note  that  go thos t byname (  )  requires  a  pointer  only  in  this  case  */ 
broadcaster. address  =  ge t hos t byname(broadc as t e r.name ) ; 

/*  clear  out  the  address  structure  */ 
bzero((char  *)&address,  s i zeof ( address )) ; 

/*  copy  the  broadcaster  address  structure  into  the  address  structure  */ 
bcopy( broadcas  ter.address ->h_addr , 

(char  * )&address . s in.addr , 
broadcas  t er.address ->h_ length) ; 

/*  set  broadcaster  port  number  above  the  svstem  reserved  ports  by  adding 
the  user’s  broadcaster  port  number  to  the  number  of  reserved  ports  */ 
broadcaster.port  =  I PPORT.RBS ERVED  +  port.number; 

/*  broadcaster  system  address  fami ly(Internet  in  this  case)  */ 
address . s in.f ami  ly  *  AF.INBT; 

/*  place  the  broadcaster  port  number  into  the  address  structure 
in  network  byte  order  */ 
address . s in.port  =  h tons ( broadcas te r. por t ) ; 


/*  attempt  to  obtain  a  local  socket  */ 
local.socket  =  socke  t  ( AF.INET ,  SCXX.DGRAM,  0); 

i f ( local.socket  <  0) 

I 

per ror( "Rece i ve r  couldn't  open  a  local  socket:"); 

I 

e  1  se 

( 

/*  attempt  to  connect  local  socket  to  broadcaster  socket  */ 

broadcas t er.socket  =  connect! local.socket ,  (struct  sockaddr  *)&address, 

s i zeof ( addres  s ) ) ; 
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i f (broadens ter_socke t  <  0) 

I 

/*  error  occurred  in  attempting  to  iniert  broadcaster  information  */ 
perror("Receiver  couldn't  find  broadcaster:"); 

shutdown! local_iocket ,  2); 
close! local_socket ) ; 

I*  set  local_socket  so  that  negative  value  is 
always  returned  when  an  error  occurs 

*/ 

local  socket  =  broadens te r_socke t ; 

» 

else 

/*  successfully  listening  to  the  broadcaster  system  */ 
printf ("ready  to  receive  f rom  %s . \n" .broadcas t er_name ) ; 


/*  return  the  socket  number  of  the  local  system  */ 
return! local_socket ) ; 

|  /*  broadcas t_rece i ve  ♦/ 


receive.c 


a.  Calling  Protocols 


This  program  monitors  a  socket,  like  a  daemon.  It  is  spawned  transparently  to 
the  user  and  receives  its  initialization  data  through  the  command  line, 
b.  Code  and  Description 


TITLE 

MXULE 

VERSION 


ADIH3R 


In  ter -Computer  Conmun icat ion  Package 


rece 1 ve . c 


31  May  1988 
Theodore  H.  Barrow 


HISTORY: 

VERSION:  1.0 

DATE  :  6  February  1987 

AUIHOR  :  Michael  J.  Zyda 

DESC.  :  Background  proceis  to  receive  messages  over  link. 

VERSION:  2.0 

DATE  15  December  1987 
AUTEUR  :  Theodore  H.  Barrow 

DESC.  ;  Added  capability  to  get  aequence  number  from  comnand  line 
and  uae  it  to  get  offset  into  shared  memory  segment. 

VERSION:  3.0 

DATE  :  31  May  1988 

AUTHOR  :  Theodore  H.  Barrow 

DESC.  :  Added  broadcast  receive  capability 


RECORD  OF  CHANGES 

Version*  Date  *  Author 

*  Change  Description 


Affected 
Modu 1 es 


b 


receive.c 

#include  "shared. h" 

#inciude  "gl .h” 

ma  i n( a  rge , argv) 

int  argc;  /*  argument  count  * / 

char  *argv[];  /*  pointer*  to  the  paned  in  argument*  */ 

( 

/*  we  need  to  declare  character  variable*  for  everything  paiaed  in  */ 

char  shmids t r [ 10] ;  /*  shared  segment  string  holding  the  integer  key*/ 

int  shmid;  /*  integer  pulled  out  of  the  string  */ 

char  *segment;  /*  character  pointer  to  the  shared  segment  */ 

int  receivesem;  /*  receive  semaphore  */ 

char  *shareusegmcn t ( ) ; /*  create  shared  segment  function  */ 

char  mname[100];  /*  machine  name  */ 

char  portstr[10];  /*  port  number  string  */ 

long  portnum;  /*  port  number  pulled  from  the  string  */ 

char  se rverflO];  /*  server  string  */ 

char  seqnos t r f 10] ;  /*  sequence  #  string  holding  integer  sequence  #  */ 

long  sequencenum  =  0;  /*  integer  pulled  out  of  the  string  (default  0)  */ 

int  socket;  /*  the  opened  socket  descriptor  */ 

int  connec t_server( ) ; 

int  connec t_c 1 ient () ; 

int  broadcas t_recei ve( ) ; 

int  rece i ve r_i s_f ree ( ) ; 

int  rece i ve r_shou 1 d_di e( ) ; 

int  eemtran();  /*  semaphore  creation  routine.  */ 

/*  pull  out  the  strings  from  the  argument  list  */ 
i  f (argc  <  5 ) 

« 

pr in t f ( "RECEIVE:  incorrect  argument  count l\n"); 
exit(l); 

I 

/*  pull  out  the  shared  memory  string  */ 
s  t  rcpy ( shmids  t  r , a rgv [ 1 ] ) ; 
sscanf  (  shmids  t  r  ,  "ltd"  ,*«hmid  )  ; 

/*  puli  out  the  machinename  string  */ 
s  t  rcpy (mname , argv [2] ) ; 

/*  pull  out  the  port  number  string  */ 
strcpy(portstr,argv[3]); 
sscanf(portstr, "%d " ,&por  t  nun) ; 
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/*  create  the  receive  semaphore  */ 
receivesem  =  s emt  ran ( por t num)  ; 

/*  pull  out  the  client/server  string  */ 
strcpy (server, argv [4]); 

/*  pull  out  the  sequence  number  string  */ 
if(  argc  >  4  ) 

s  t  rcpy ( seqnos  t  r  ,  a  rgv [5 ]  )  ; 
s  scanf ( seqnos  t  r , "%d" ,&sequencenum) ; 

I 

/*  attach  to  the  shared  memory  segment  */ 
i  f  ((  in  t )(  segment  =  (char  *  )  shina  t  (  shmi  d ,  0,  0666))  <  0) 

I 

per ror ( "RECEIVE: shmat ” ) ; 
exi t (0) ; 

I 

/*  create  the  shared  segment  address  to  use  */ 
segment  +=>  sequencenum  *  M4XSHAREDS I ZE ; 

/*  open  the  socket  connection  to  the  named  machine  */ 
i f ( s t rcmp( server server" )  ==  0) 

/*  we  should  open  as  the  server  */ 
socket  =  connec t _se rve r  (mname , por t num) ; 

I 

else  i f ( s t rcmp( server rece ive" )  ==  0) 

( 

/*  we  should  open  as  the  broadcast  receiver*/ 
socket  =  b r oadc a s t _rece i ve  (mname , po r t num) ; 

I 

e  1  se 

( 

I*  we  should  open  as  a  client  ♦/ 
socket  =  connect  c 1 i en t  (mname , por t num) ; 

) 

/*  check  to  make  sure  socket  was  opened,  exit  if  not  ♦/ 
if(socket  <  0) 

( 

pr int f ( "RECEIVE:  socket  connection  NOT  madel\n"); 
exi t ( 1 ) ; 

) 


/*  the  infinite  loop...  */ 

i  f  (  s  t  rcmp(  server, 11  receive")  ==  0) 
whi le(TRUE) 

( 

/*  should  the  receiver  die?77  */ 
if(receiver  should  di e ( segmen t  ,  r ece  i  ve sem) ) 

( 

/*  exit  after  detaching  shared  segment  and  cleaning  up  socket  */ 
de  t  achsharedsegment ( segment ) ; 
shutdown! socket ,  0); 
c lose( socke  t ) ; 
exi t (0) ; 

I 

/*  if  the  receiver  part  of  the  segment  is  free,  read  onto  it  */ 
if(receiver  is  f ree ( segmen t  ) ) 

( 

/*  check  socket  and  read  into  segment  if  proper  message  */ 
i  f ( broadc a s t_i n t o_segmen t ( socke t , segmen t , mname , por t num)  >  0) 
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/*  at  this  point,  sleep  until  we  receive  a  signal  from  the 
graphics  program  that  the  receiver  segment  ia  free,  i.e. 
the  data  has  been  read  ont  */ 

P(receivesem) ; 

) 

) 

/*  end  while  true  for  broadcasting*/ 
e 

whi le(TRUE) 

I 

/*  should  the  receiver  die???  */ 

1 f ( recei ver_*houl d_di e ( segment , rece ivesem) ) 

/*  exit  after  detaching  shared  segment  and  cleaning  up  socket  */ 
de  t  ach shared segment ( segment ) ; 
shut  down (socket ,  0) ; 
c 1 ose( socke  t ) ; 
exi t (0) ; 

» 

/*  if  the  receiver  part  of  the  segment  is  free,  read  onto  it  */ 
if(receivcr_is_free( segment ) ) 

I 

/*  read  socket  into  segment  */ 

read_ socket  into_ segment ( socket , segment ) ; 

» 

/*  at  this  point,  sleep  until  we  receive  a  signal  from  the 
graphics  program  that  the  receiver  segment  is  free,  i.e. 
the  data  nas  been  read  out  */ 

P( receivesem) ; 


|  /*  end  while  true  for  direct  connections*/ 


S.  semaphore.c 


a.  Calling  Protocols 


This  module  repackages  the  low-level  semaphore  calls  into  a  P  and  a  V 
semaphore  operation.  No  functions  in  this  module  are  intended  for  application  programs, 
b.  Code  and  Description 


TITLE 

MXXJLE 


VERSION 


AUTHOR 


Inter-Computer  Comnunicat  ion  Package 

send . c 

1.0 

11  February  1987 
Michael  J.  Zyda 


HISTORY: 

VERSION 


AUTHOR 

DESC. 


11  February  1987 
Michael  J.  Zyda 

Implements  P  and  V  semaphore  operations  for  Unix  system  V. 
Based  on  an  example  from  Advanced  Unix  Progr aitmi ng . 


RECORD  OF  CHANOES 

Version*  Date  *  Author 

•  Change  Descriotion 


Affect  ed 
Modu lea 


semaphores 

finclude  <sy s / t ype s . h> 

#include  <sys/ipc.h> 

#include  <sys/sem.h> 

int  semt  ran(key )  /*  translate  semaphore  key  to  ID  */ 
int  key; 

I 

int  s i d ; 

if  ((aid  =  semgetilkey  t  )key , 1 , 0666 1  I PC_CREAT ) ) 

I 

per ror ( "semge  t " ) ; 


return! s id) ; 


static  void  seme  a  1 1 ( s i d , op )  /*  call  semop  */ 
int  s i d ; 
int  op; 

I 

struct  sembuf  sb; 

sb  .  setn_num  =  0; 
sb . sem_op  =  op; 
sb  .  sem_f  1  g  =  0; 

i f 1 semop! s i d ,&sb ,  1 )  ==  -1) 

I 

pe  r  ror ! " semop” ) ; 


void  Pisid)  /*  acquire  semaphore  */ 
int  sid; 

1 

s  emc  allisid,  -1); 

) 


void  V!sid)  /*  release  semaphore  */ 
int  sid; 

{ 

s  emc  allisid,  1); 

I 


iVrf'.V.V.V 


/.v.v.v.avw  <*; 
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#include  "shared. h 
#inc lude  "gl . h" 

ma  i  n  ( a  r  gc  ,  a  rgv ) 


int  argc;  /*  argument  count  */ 

char  *a rgv [ ] ;  /*  pointers  to  the  passed  in  arguments  */ 

I 

/*  we  need  to  declare  character  variables  for  everything  passed  in  */ 


char 

shmidst  r [10] ; 

/* 

shared  segment  string 

holding  the  integer 

shmid  */ 

int 

shmi  d ; 

/* 

integer  pulled  out  of 

t  he 

string  */ 

char 

•segment  ; 

/* 

character  pointer  to 

the 

shared  segment  */ 

int 

sendsem; 

/* 

send  semaphore  •/ 

char 

•sharedse  gmen  t ( ) ; 

/* 

create  shared  se  gme n  t 

f unc  t i on  • / 

char 

mname  [  100]  ; 

/* 

machine  name  */ 

char 

por t  s  t  r [ 10] ; 

/* 

port  number  string  */ 

long  portnum; 

/* 

port  number  pulled  from  the  string  */ 

char 

se  r ve  r [  10] ; 

/* 

server  string  */ 

char 

seqnos  t  r [ 10] ; 

/* 

sequence  #  string  holding 

integer  sequence 

#  */ 

long 

sequencenum  =  0; 

i* 

integer  pulled  out  of 

the 

st  ring  (defaul t 

0)  •/ 

int 

socke  t  ; 

1* 

the  opened  socket  descriptor  */ 

int  connec t_ierver(  )  ; 
int  connec t_c I i en t () ; 
int  start_broadcast ( ) ; 
int  sende r_has_da t a( )  ; 
int  sende r_ shou 1 d_di e ()  ; 

int  semtranO;  /*  semaphore  creation  routine.  */ 


/*  pull  out  the  strings  from  the  argument  list  */ 
i f (argc  <  5 ) 

( 

pr i n t f ( ”SEM):  incorrect  argument  countl\n"); 
ex i t ( I ) ; 

I 

/*  pull  out  the  shared  memory  string  */ 
st  rcpy ( shmi ds  t  r , a rgv [ 1  ]  )  ; 
s  sc  an  f  (  shmi ds  t  r , "%d" ,&■ hmi  d  )  ; 

/*  pull  out  the  machinename  string  */ 
s  t  rcpy  (mn  ante  ,  a  rgv  [2  ]  )  ; 

/*  pull  out  the  port  number  siring  */ 
strcpy(porlstr,argv[3J); 
sscanf(portstr,  "%d" ,&portnum) ; 

/*  create  the  send  semaphore  */ 
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sendsem  =  semt  r an ( por t num)  ; 


/*  pull  out  the  c  I  ien t / a ervet  string  */ 
atrcpy(server,argv[4]); 


/*  pull  out  the  sequence  number  string  */ 
i  f (  a  rgc  >  4  ) 


it  rcpy( seqnost  r , »  r  gv ( 5 | ) ; 
s  scanf ( seqnostr, "%d" ,A« equencenum) ; 


/*  attach  to  the  shared  memory  segment  */ 
i  f  ((  in  t  )(  segment  =  (char  *)  shina  t  (  shmi  d ,  0,  0666))  <  0) 


pe r  ror  (  "SEM):  shina t  "  )  ; 
exi 1(0); 


I*  create  the  shared  segment  */ 
segment  +=  sequencenum  *  MAXSHAREDS 1 ZE ; 


I*  open  the  socket  connection  to  the  named  machine  */ 
i  f t s t r cmp( se r ve r , ” se r ve r " )  =»  0) 


/*  we  should  open  as  the  server  *1 
socket  =  connec t_ se r ve r  (mn  ame , por t num) ; 


:lse  if(  strcmp(  server,  "broadcast"  )  ==  0  ) 


I*  we  should  open  as  a  broadcaster  */ 
socket  =  s t a r t_broadcas t (  portnum  ); 


/*  we  should  open  as  a  client  */ 
socket  =  connec t_c 1 i en t  (mname , por t num) ; 


/*  check  to  make  sure  socket  was  opened,  exit  if  not  •/ 
i  f ( socke  t  <  0 ) 


p r i n t f ( "SEM):  socket  connection  NOT  made!\n"); 
ex i t ( 1 ) ; 


/*  the  infinite  loop...  */ 


if(  sir cmp (  server,  "broadcast”  )  ==  0  ) 
wh i 1 e ( TRUE ) 

I 

/•  should  the  sender  die?77  •/ 
if(sender_should_die( segment , send  s  em) ) 

( 

/*  exit  after  detaching  segment  and  cleaning  up  socket  */ 
de  t  ach  sha  r  edsegmen I ( segmen  t ) ; 
shu t down ( socke t ,  1); 
close(socket); 
exi t (0) ; 


/*  if  there  is  data  in  the  shared  memory  se gm'n t ,  ...  * / 

if( sender _h as _d at a( segment ) ) 


/*  write  the  data  in  the  shared  segment  onto  the  socket  */ 
send_socket_fr  om_ segmen l(socket .portnum, segmen  t ) ; 


AmS 


/*  it  this  point,  sleep  until  we  receive  •  signil  from  the  graphics 
program.  The  signal  will  indicate  that  the  graphics  program 
has  put  more  data  into  the  shared  segment. 

*/ 

P( sendsem) ; 

)  /*  end  while  true  for  broadcasting*/ 

se 

wh i 1 e ( TRUE ) 

( 

/*  should  the  sender  die1??  */ 
i  f ( sender  shou ld_di e ( segmen  t , sendsem) ) 

I 

/*  exit  after  detaching  segment  and  cleaning  up  socket  */ 
de  t  achsharedsegmen t ( segment ) ; 
shutdown! socket ,  1); 
close( socket ) ; 
e  x  i  t ! 0 ); 

) 

/*  if  there  is  data  in  the  shared  memory  segment,  ...  */ 
iffsender  has  dat a! segment ) ) 

I 

/*  write  the  data  in  the  shared  segment  onto  the  socket  */ 
wri te_socket_f rom_  segment ( socket , segment ) ; 

1 

/*  at  this  point,  sleep  until  we  receive  a  signal  from  the  graphics 
program.  The  signal  will  indicate  that  the  graphics  program 
has  put  more  data  into  the  shared  segment. 

*/ 

P(  sendsem)  ; 

)  /*  end  while  true  for  direct  connection*/ 
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7.  shared.h 

a.  railing  Protocols 


This  module  has  all  the  predefined  constants  and  type  definitions.  It  must  be 


included  in  the  application. 


shared. h 


Code  and  Description 


TITLE  :  In  ter -Computer  Communication  Package 
MXXJLE  :  shared .h 
VERSION:  4.0 

DATE  :  15  December  1987 
AUTHOR  :  Theodore  H.  Barrow 


HISTORY: 

VERSION:  1.0 

DATE  :  6  February  1987 

AUTHOR  :  Michael  J.  Zyda 

DESC.  :  Contains  all  defines  and  special  constants  for  shared 
memory  socket  system. 

VERSION:  2.0 

DATE  :  27  May  1987 

AUIHTR  :  Theodore  H.  Barrow 

DESC.  :  Added  a  typedef  of  structure  for  use  by  various  routines. 

Added  message  types  for  high  level  read/write  protocol. 

VERSION:  3.0 

DATE  :  21  October  1987 

M'THDR  :  Theodore  H.  Barrow 

DESC.  :  Changed  dependencies  of  buffer  calculation  constants  so  that 
only  one  need  change.  Added  additional  message  types. 


shared,  h 


/* 

the  following  3  define*  are  the  changeable  parameter* 

LAROESTREAD  MJST  be  diviaible  by  4 

*/ 

•define  SEfOLOGATIGN  " /u ■ r /work/bar row/ *ha re3 /tend"  /*  the  name  of  the  program 

to  ran  for  the  tender  */ 

#define  RECEIVELOCATICN  " /usr/work/ba r row/ *hare3/ recei ve"  /*  the  name  of  program 

to  run  for  the  receiver  */ 

#de  f i ne  LAROESTREAD  252  /*  the  large*!  read  (i.e.  buffet  *ize)  */ 


/*  The  following  define*  are  constants  or  are  derived  from  LAROESTREAD  */ 

#define  SENDEROFFSET  (LAROESTREAD  +  <)  /*  the  tender  data  itarts  here  */ 

•define  AM5ENDEROFFSET  ( SENDEROFFSET  /  4)  /*  long  word  offaet  for  tender  data  */ 

#define  RECEIVEROFPSET  0  /*  the  receiver  data  *tarts  at  byte  0  */ 

#define  VWECE1VEROFPSET  0  /*  the  receiver  data  itart*  at  long  word  0  */ 

#de fine  PROTOOOLHOLDOFFSET  ( SENDEROFFSET  *  3)  /*  holding  area  atari*  after 

sender  area  */ 

#define  MAXSHAREDSIZE  ( PROTOOOLHDLDOFFSET  +  12)  /*  the  number  of  byte*  in  the 

shared  segment  */ 


#def ine  CHARACTER  TYPE 

#def ine  INTEGERTYl’E 

#de fine  FLQAT_TYPE 

#def  i  ne  CHARACTER  ARRAY  TTPE 

#de  f  i  ne  INTEOER  ARRAY  TYPE 

#de fine  FLOAT  ARRAY  TYPE 


’B’  /*  code  for  characters  */ 

’I’  /*  code  for  integers  •/ 

’R’  /*  code  for  float*  */ 

’C’  /*  code  for  character  array*  */ 

’I’  /*  code  for  integer  array*  */ 

'S’  /*  code  for  float  array*  */ 


# define  CHARACTER_S IZE  1 

#de f i ne  INTEQER_SI2E  sizeof(l) 


#de fine  FLQAT.SIZE 


/*  character  size  in  byte*  */ 
/*  integer  size  in  byte*  */ 


tizeof(l.O)  /*  float  *ize  in  byte*  •/ 


/*  the  following  is  the  structure  type  definition  needed  for  each  machine 
you  want  to  comnunicate  to... 


typedef  struct  { 


char 

**egmen  t  ; 

/• 

int 

ahmid; 

r 

ini 

send sem; 

/* 

*/ 

int 

receiveaem; 

/* 

*/ 

process. 


receiver  process... 


|  Machine  ; 


ns 


8.  shareseg.c 


a.  Calling  Protocols 

This  module  contains  the  low-level  shared-memory  calls.  No  functions  in  this 
module  are  intended  for  application  programs. 

b.  Code  and  Description 


/' 


TITLE 

MHULE 

VERSION 

DATE 

AUIHOR 


Inter -Computer  Cottmun i c a t  i on  Package 

shareseg . c 

3.1 

24  February  1988 
Theodore  H.  Barrow 


HISTORY: 

VERSION:  1.0 

DATE  :  6  February  1987 

AUIHOR  .  Michael  J.  Zyda 

DESC.  :  Contains  routines  to  manage  shared  memory  segment.  Creation 
attachment,  detachment  and  deletion  are  all  covered. 

VERSION:  2.0 

DATE  :  21  October  1987 

AUTHOR  :  Theodore  H.  Barrow 

DESC.  :  Added  function  dynami c sha r edsegmen t  to  allow  dynamic  memory 
allocation  after  communications  link  established. 

VERSION:  3.0 

DATE  13  December  1987 

AUIHOR  :  Theodore  H.  Barrow 

DESC.  :  Modified  function  dynami  c sha red segmen t  for  use  with  multiple 
links.  First  call  does  shared  segment  creation.  Subsequent 
calls  return  address  for  the  next  buffer  set. 


RECORD  OF  CHANGES 

Version*  Date  *  Author 

*  Change  Description 


3.1  ♦  24Feb88*  T.  H.  Barrow  * 

•  Added  compatibility  for  IRIS  4D, 


Affected 
Modu 1 es 


Reqd 

Vers 


shareseg.c 


♦  include  <sy s / «y smac rot . h> 

♦include  <«tdio.h> 

♦include  <sy s / t ype s . h> 

♦include  <*ys/ipc,h> 

♦  include  <sys/shm.h> 

♦ i nc I ude  <g 1 . h> 

/♦  The  following  defines  will  hsve  to  be  modified  for  different  machines 
but  one  of  the  underlying  shared  memory  attachment  mechanisms  should 
work  for  any  system  V  implementation.  */ 

♦define  IRIS4D  1 
♦define  IRIS3000  2 
♦ifdef  FLAT 

♦define  MACHINE  IRIS4D 

♦  e  1  se 

♦define  MACHINE  IRIS3000 
♦end i f 

char  *sharedsegment (key  , nby tes , shmid) 
long  key;  /*  the  key  to  use  for  the  segment  */ 

long  nbytes;  /*  the  number  of  bytes  in  the  segment  */ 
int  *shmid;  /*  returned  shared  memory  id  name  */ 


char  *buf;  /*  temp  char  pointer  ♦/ 

struct  shmid_ds  junkbuf;  /*  1  don’t  care  what’s  in  this  buffer  */ 
/*  allocate  a  shared  memory  segment  */ 

if(  (*shmid  =  shmget(  key,  nbytes,  0666  I  IPC_CREAT  ))  <  0  ) 

I 

pe  r  ro  r  (  "  s hinge  t  "  )  ; 
e  x  i  t  ( 0 ) ; 

) 

/*  attach  to  the  shared  memory  segment  */ 
if((int)(buf  =  (char  *  )  shmat ( * shmi  d ,  0,  0666))  <  0) 

I 

pe  r tor ( " shmat  * ) ; 

/*  Since  there  was  an  attachment  error,  delete  the  segment  */ 
if(  shmctl(  shmid,  IPC_RM1D,  &junkbuf  )==-!) 

perror(  "shmct 1  "  ) ; 
eai t (0) ; 

I 


/*  return  the  pointer  to  the  shared  segment  */ 
return(buf ) ; 
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char  *at tach_wi t h  i  n_da t a segmen t (  key,  size,  shmid,  freeapace  ) 
long  key;  /*  the  key  to  use  for  the  segment  */ 

long  size;  /*  the  number  of  bytes  in  the  segment  */ 

int  *shmid;  /*  returned  shared  memory  id  name  */ 

int  freespace;  /*  amount  freeapace  desired  for  dynamic  allocation  * / 


char  *enddata,  *buf;  /*  temporary  address  pointers  */ 

struct  shmid_ds  junkbuf;  /*  I  don't  care  what’s  in  this  buffer  */ 
char  *sbrk(),  *malloc(); 

/*  allocate  a  shared  memory  segment  *1 

iff  (*shmid  =  shmget(key,  size,  0666  I  IPC_CREAT))  <  0  ) 

1 

per ror ( " shmge t " ) ; 
exi t (0) ; 

I 

/*  Ensure  at  least  as  much  unallocated  space  as  freespace  indicates. 
Normally  the  top  of  the  data  region  is  incremented  more  than  the 
minimum  required  to  meet  the  malloc()  request.  Using  malloc() 
and  free()  ensures  that  this  mechanism  is  available  for  subsequent 
dynamic  memory  allocations.  Direct  use  of  sbrk( )  system  call 
causes  the  malloc()  mechanism  to  fail  on  subsequent  allocation 
requests.  freespace  is  cast  to  unsigned  to  meet  malloc()  spec.  */ 
free(  malloc(  ( uns i gned) f ree space  )); 

/*  find  the  top  of  data  region  */ 
enddata  =  sbrk(0) ; 

/*  round  up  to  the  next  page  boundary  for  attachment  of  shared 
memory  segment  */ 

buf  =  (char  *  )  ( ( int  )enddat  a  -  ( ( i n t  )endda  t a  %  SfMLBA)  +  SfMJIA)  ; 

/*  reset  top  of  data  region  to  be  above  shared  segment  •/ 
if(  brk(  buf  +  size  )  <  0  ) 

I 

perror( "brk" ) ; 

/*  Since  there  was  an  error,  delete  the  segment  */ 
if(  shmctl(  shmid,  IPC_HMID,  Ajunkbuf  )  ==  - 1  ) 
pe  r  ror (  ”  shmc  t  1  ”  ) ; 
exi t ( -  1 ) ; 

) 

/*  attach  to  the  shared  memory  segment  at  the  calculated  address  */ 
iff  (  in t ) shma t ( *shmi d ,  buf,  0666)  <  0  ) 

( 

pe  r ror ( ” shma t  "  )  ; 

/*  Since  there  was  an  attachment  error,  delete  the  segment  */ 
iff  shmctl(  shmid,  IPC_FMID,  Ajunkbuf  )  ==  -  1  ) 
per ror (  "  shmct 1 "  )  ; 
ex i t ( 0 ) ; 

I 

return(  buf  ); 

)  /*  a 1 1 ach_wi t h i n_da t a segmen t (  )  */ 
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char  ‘dynamicsharedsegment {nunroachines ,  key,  nbytes,  ahmid,  freeapace) 
ini  numnachines  ;  /*  maximum  number  of  machinea  to  be  initiated  */ 
long  key;  /*  the  key  to  uae  for  the  aegment  */ 

long  nbytea;  f*  *he  number  of  bytea  in  the  aegment  */ 

int  *shmid;  /♦  returned  ahared  memory  id  name  */ 

int  freeapace;  /♦  amount  freeapace  deaired  for  dynamic  allocation  */ 

( 

atatic  Boolean  firattime  =  TRUE;  /*  allowa  for  multiple  calla  */ 

atatic  char  *  a t a r t aha  red ;  /*  atart  of  ahared  memory  apace  */ 

atatic  int  *holdshmid;  /*  holda  ahmid  for  aubaequent  calla  */ 

i  f (  f  i  r  a  t  t ime  ) 

( 

switch!  MACHINE  ) 

I 

caae  IRIS4D: 

startshared  =  aha  redsegment  (  key,  nuttmach  i  nea  *nby  t  e  a  ,  ahmid  ); 
break ; 

case  IRIS3000: 

startshared  =  (char  * ) a t t ach_wi t h i n_da t a segmen t (  key, 

numnach i ne a*nby t e a ,  ahmid,  freeapace  ); 

break; 
default  ; 

perror(  "ahareaeg:  Unknown  machine"  ); 

)  /♦  switch(  MACHINE  )  */ 

holdshmid  =  shmid; 
first  time  =  FALSE; 

) 

else 

( 

/*  start  next  buffer  inmediately  above  last.  Return  the  a  nine  ahmid 
for  all  buffers.  Assumes  all  buffers  are  same  size  (true  if  all 
from  same  shared. h  definition.  */ 
startshared  +=  nbytes; 

♦shmid  =»  ‘holdshmid; 

I 

/*  return  pointer  to  the  proper  buffer  in  the  ahared  segment  */ 
return!  startshared  ); 
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de  t  ach shared segmen t (segment  ) 

char  ’segment;  /*  segment  to  detach  from  •/ 

( 

int  returnvalue; 

if(  (int)  segment  %  SIM.BA  1=0  ) 
return(  1  ); 
else 

I 

if(  returnvalue  =  shmd t ( segmen t )  <  0  ) 
pe  r  ror ( " shmd  t "  ) ; 
return(  returnvalue  ); 

I 

I 


deletesharedsegment( segment , shmid) 

char  ’segment;  /*  character  pointer  to  the  shared  segment  */ 
int  shmid;  /*  shared  memory  id...  */ 

I 

int  returnvalue; 

struct  shmid_ds  junkbuf;  /*  I  don’t  care  what’s  in  this  buffer  */ 

/*  detach  from  the  shared  segment  and  set  returnvalue  ’/ 
if(  returnvalue  =  de t ach sharedsegmen t ( segmen t  )  ==  0  ) 

/*  remove  the  shared  segment  from  the  system  and  reset  returnvalue  */ 
if(  returnvalue  =  shmc  t T( shmid ,  IPCJRMID,  &junkbuf)  <  0  ) 
pe  r  ror ( " shmc  1 1 "  ) ; 


return! returnvalue); 
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a.  Calling  Protocols 

This  module  contains  functions  that  ate  intended  for  the  application’s  use  and 
functions  that  are  used  exclusively  by  other  routines.  The  parameters  for  externally 
accessible  functions  are  described  below. 
receiver _has_data 

int  receiver_has_data( instructure) 

Machine  * i ns t rue t ure ;  /*  includes 

char  *instructure . segment  a  pointer  to  the  shared  segment  *1 

ii.  sender Js-free 

int  sende r_i s_f ree( ins t rue ture ) 

Machine  * i ns t rue t ure ;  /*  includes 

char  *  ins t rue ture . segment  a  pointer  to  the  shared  segment  */ 
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b.  Code  and  Description 


TITLE  :  Inter-Computer  Communication  Package 

MXXJLE  :  support.c 

VERSION:  4.0 

DATE  :  31  May  1988 

AUTHOR  :  Theodore  H.  Barrow 


HISTORY: 


VERSION 


AUTHOR 


VERSION 


AUTHOR 


VERSION 


AUTHOR 


VERSION 


AUTHOR 


6  February  1987 
Michael  J .  Zyda 

Contains  support  routines  for  shared  memory  cotimun  i  ca  t  i  ons 
system. 


27  May  1987 
Theodore  H.  Barrow 

Converted  functions  called  by  the  application  program  to  use 
a  structure  for  ease  of  use. 


21  October  1987 
Theodore  H.  Barrow 

Removed  functions  for  reading  from  and  writing  to  the  shared 
memory  segment  by  the  application  program. 


31  May  1988 
Theodore  H.  Barrow 

Added  functions  b r oadc a s t _ i n t o_s egmen t  and 

send_8ocke t _f rom_ s egmen t  for  broadcasting  over  datagram  socket 


RECORD  OF  CHANGES 

Version*  Date  *  Author 

*  Change  Description 


Af  fee  ted 
Modu I e  s 


•Reqd 

♦Vers 


•  •*•*•»*»•*»»*  , 
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•include  "shared, h" 

#inc lude  <gl . h> 

#include  <bsd/ sy s/ t ype s . h> 

•include  <sy a/ tocke t . h> 

•include  <bsd/ne t i ne t / i n . h> 

•include  <bid/netdb.h> 

/*  the  following  routine  tell  up  buffer  area  */ 
ini t_shared_buf  fer( aegment ) 

char  ‘segment;  /*  pointer  to  the  ihared  segment  */ 

( 

free_sender(  segment  ); 
f ree_receiver(  segment  ); 

•(segment  +  PRaitWDLHOLDOFFSET  +  9)  =  ’\0’; 

1 


/*  the  following  routine  writes  zeroes  at  the  top  of  the 

shared  segment  indicating  that  the  segment  data  is  no  longer 
valid. 

*/ 

free_sender( segment ) 

char  ‘segment;  /•  pointer  to  the  shared  segment  */ 

I 

/*  the  following  line  zeroes  the  first  four  bytes  of  the  sender  part 
of  the  shared  memory  segment,  ’segment’  is  a  character  pointer. 

I  coerce  it  into  a  long  integer  pointer  and  then  write  a  zero. 

*/ 

•((long  *) aegment  +  W5EPOEROFFSET )  =  0; 

I 


/•  this  following  routine  writes  zeroes  at  the  lop  of  the 

shared  segment  indicating  that  the  segment  data  is  no  longer 
valid. 

*/ 

free_ receiver! segmen  t ) 

char  ^segment;  /•  pointer  to  the  shared  segment  •/ 

( 

/*  the  following  line  zeroes  the  first  four  bytes  of  the  receiver  part 
of  the  shared  memory  segment,  'segment'  is  a  character  pointer. 

I  coerce  it  into  a  long  integer  pointer  and  then  write  a  zero. 

*/ 

•((long  *)segment  +  WRECE I VEROFFSET )  ■  0; 


I 
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/*  the  following  routine  tests  the  first  4  bytes  of  the  receiver 
segment  to  see  if  they  are  non-zero. 

it  uses  an  input  structure  since  called  by  main  program 

*/ 

int  receiver_has_data( inst  ructure) 

Machine  * i n s t r uc t u r e  ;  /♦  includes 

char  * i n s t r uc t u r e . s egmen t  a  pointer  to  the  shared  segment  */ 

1 

if(*((long  *  )  i ns  I  rue t ure ->segmen t  +  \*RECEIVHlOFFSET)  >  0) 
r  e  t  u  r  n ( TRUE ) ; 

) 

else 

I 

r  e  t  u  r  n ( FALSE ) ; 

I 


/*  the  following  routine  tests  the  first  4  bytes  of  the  sender 
segment  to  see  if  they  are  non-zero. 

*/ 

int  sende r_ha s_da t a ( segmen t  ) 

char  'segment ;  /*  pointer  to  the  shared  segment  */ 


if(*((long  *)  segment  +  VSEbOEROFFSET >  >  0) 
return! TRUE ) ; 

I 

else 

( 

r  e  t  u  r  n ( FALSE )  ; 

I 


1 


4 


& 
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/*  the  following  routine  test*  the  first  4  byte*  of  the  receiver 
segment  to  see  if  they  are  less  than  zero. 

*/ 

int  rece i ver_*hou 1 d_di e ( segmen t ) 

char  'segment;  /•  pointer  to  the  shared  segment  •/ 


if(*((long  *)segment  +  MWECEIVEROFFSBT)  <  0) 

( 

re  turn(TRUE) ; 

I 

el  se 

I 

re  turn(FALSE) ; 

I 


/*  the  following  routine  teats  the  first  4  bytes  of  the  sender 
segment  to  see  if  they  are  less  than  zero. 

»/ 

int  sende r_shou 1 d_die ( segmen t  ) 

char  'segment;  /*  pointer  to  the  shared  segment  */ 


if(*((Iong  *)segment  +  \W5EhDEROFFSET)  <  0) 

I 

re turn(TRUE) ; 

) 

e  I  ae 

I 

return(FALSE) ; 
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/*  the  following  routine  tests  the  first  4  bytes  of  the  receiver 
segment  to  see  if  they  are  non-zero. 

*/ 

int  rece i ve r_i s_f ree ! segmen t ) 

char  ‘segment;  /*  pointer  to  the  shared  segment  */ 

( 

if(*((long  *)segment  +  WRECEIVEROFFSET)  ==  0) 

I 

r  e  t  u  r  n ( TRUE ) ; 

I 

else 

( 

return! FALSE )  ; 

I 


/*  the  following  routine  tests  the  first  4  bytes  of  the  sender 
segment  to  see  if  they  are  non-zero. 

it  uses  an  input  structure  since  called  by  main  program 


int  s e nde r_i s_ f r ee ( i n s t r uc t u r e ) 

Machine  *  i  n s t r uc t u r e  ;  /*  includes 

char  *  i  n s t rue t u re  .  segmen t  a  pointer  to  the  shared  segment  */ 

I 

if(*((long  *  )  i  ns  t  rue  t  ure ->segmen  t  t-  WSENDEROFFSET)  ==  0) 

I 

return! TRUE ) ; 

) 

else 

I 

return! FALSE )  ; 
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/*  the  following  routine  retd*  on  the  input  socket  into  the  receiver  segment.*/ 

read_socket_into_segment( locket , segment ) 

int  socket;  /*  a  socket  descriptor  */ 

char  ^segment;  /*  a  ptr  to  the  shared  segment  */ 


long  nbytes;  /*  the  number  of  bytes  read  in  */ 
char  t emp [ LARGBSTOEAD]  ; 

/*  read  the  data  into  a  temporary  array  to  avoid  sesment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segment . 

V 

nbytes  =  read(  socket ,  temp, LARGESTRBAD)  ; 
if (nbytes  <=  0) 

/*  the  following  routine  calls  are  carmiented  out  for  the  following 
reason: 

nbytes  <=  0  means  that  the  socket  has  been  broken. 

This  routine  is  called  by  the  receiver  process  so  the  only 
intelligent  thing  to  do  is  to  terminate  the  receiver  process, 
i  .  e  .  call  exi t . . . 

perror(" read" ) ; 

p  r  i  n  t  f  (  "READ_SOCKEr  INTO_SECMiNr :  number  of  bytes  read  *  %d\n"  .nbytes) ; 

*/ 

shutdown!  socket,  2  ); 
close(  socket  ); 
exi t( 1) ; 


/*  copy  the  data  into  the  shared  segment  ♦/ 
memcpy! ( segment  +  RECEIVEROFFSET  +  4 ) , t  emp , nby t e s ) ; 

/*  set  the  number  of  bytes  in  the  shared  segment  */ 
•((long  *)segment  +  VRECEIVEROFFSET)  ■  nbytes; 
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/*  the  following  routine  writes  the  data  from  the  sender  side 
of  the  shared  segment  to  the  socket  */ 


wr i t  e_socke t_f  rotn_ segment ( socke  t , segment ) 

int  socket;  /*  socket  descriptor  */ 

char  *segment;  /♦  pointer  to  the  shared  segment  */ 

I 

long  nbytes;  /*  the  number  of  bytes  to  write  */ 
char  t emp[LARGESTREAD] ; 

/*  copy  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segment  . 

*/ 

memcpy( temp ,( (char  *)segroent  +  SEMJEROFFSET  +  4), 

♦((long  *)segment  +  WSENDEROFFSET) ) ; 

/*  write  the  data  to  the  socket  */ 

nbytes  =  wr i t e ( socke t , t emp ,  ‘((long  *) segment  +  WSEM)EROPPSET) ) ; 
if(nbytes  <=  0  II  nbytes  1=  ♦((long  ♦)segment  +  \M5EM5EROFFSET) ) 

/* 

This  error  indicates  the  socket  is  broken.  Jnst  exit  the 
sender  process . 

pe  r  ror ( "wr  i t  e"  )  ; 

pr  in  t  f  (  "\WITE_SOCXET_FRCM_SECMBr'n':  number  of  bytes  written  =  %d\n"  ,  nbytes  ) ; 
r int f ( "Number  of  bytes  in  shared  segment  =  %d\n" , *( ( long  *)segment  +  WSEM3EROFFSET) ) ; 

shutdown!  socket,  2  ); 
close(  socket  ); 
exi t ( 1 ) ; 


) 


/*  free  the  sender  segment  */ 
free_sender( segment  ) ; 


supportc 


/*  The  following  routine  receive*  on  the  input  datagram  socket. 

If  the  message  matches  the  mname  :r.d  portnum  it  is  copied  into  the 
receiver  area  of  the  shared  memory  segment. 

0  is  returned  if  the  message  does  not  match  mname  and  portnum, 
the  number  of  bytes  read  is  returned  if  it  does  match.  */ 

int  broadcas t_in t o_segmen t ( socket , segment , mname  .portnum) 

int  socket;  /*  a  socket  descriptor  */ 

char  *segment;  /♦  a  ptr  to  the  shared  segment  */ 

char  mname [ ] ;  /*  machine  name  of  broadcaster  */ 

long  portnum;  /*  port  number  of  broadcaster  */ 

1 

long  nbytes;  /*  the  number  of  bytes  read  in  */ 

char  temp[ LARGER IkEAD ] ; 

int  flags  =  0;  /*  flags  ■  0  indicates  none  set  */ 

struct  *ockaddr_in  who;  /*  Internet  structure  for  message  sender  address  */ 

int  wholen;  /*  length  of  received  addren  struct  who  */ 

struct  hostent  ‘broadcaster;  /*  pointer  to  structure  with  info  on 

broadcaster  */ 

static  long  broadcas t_addre s s ;  /*  address  of  broadcaster  */ 
static  short  broadcas t_por t ;  /*  port  of  broadcaster  */ 

static  Boolean  first  time  a  TRUE; 


/*  read  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  tne  shared  memory 
segment.  This  also  allows  checking  for  match  with  desired  broadcaster. 

*/ 

nbytes  ■  recvfromf  socket,  temp,  LARGBSTREAD.  flags, 

(struct  sockaddr  *)&who,  Awholen  ); 


if(nbytes  <=  0) 

( 

perror( "recvfrom:  ") ; 

I 

el  se 

I 

i f (  f 1 r  s  1 1 ime  ) 

l 


/*  determine  desired  broadcaster  address  and  port  */ 
broadcas t_por t  a  htons((short ) portnum) ; 

broadcaster  s  (struct  hostent  *)gethostbyname(  mname  ); 


bcopy(  broadcaster->h_addr ,  (char  *  )&broadcast_address , 
broadcas ter ->h_length  ); 


if(  (broadcast.address 
(broadcast_port 


who . s in_addr . s_addr )  SA 
who. sin_port )  ) 
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/*  the  following  routine  sends  the  data  from  the  sender  side 
of  the  shared  segment  to  the  socket  for  broadcast  */ 


send_socke t_f rom_segment ( socket , portnum,  segment ) 
int  socket;  /*  socket  descriptor  ♦/ 

long  portnum;  /*  port  number  of  broadcaster  ♦/ 

char  *segment;  /*  pointer  to  the  shared  segment  */ 

I 

long  nbytes;  /*  the  number  of  bytes  to  write  */ 

char  tempfLARGESTREAD] ; 

short  broadcas t er_por t ; 

static  Boolean  firsttime  =>  TRUE; 

static  struct  sockaddr_in  network  =  (  AF_INET  );  /*  structure  for  broadcast 

address  */ 

i f (  f i r  s  1 1 ime  ) 

{ 

b roadc a • t e r_po r t  =  I PPORT_RESERVED  +  portnum; 

/♦  Set  up  broadcasting  address  structure  */ 
network,  si n_f ami  ly  =■  AF_ INET ; 

network.  sin_addr  .  s_addr  ■  h  t  on  1  (  INAECR_BRGADCAST) ; 
ne twork . a in_por t  =  h tons (broadcas te r_por t ) ; 

first  time  =  FALSE; 

i 

/*  copy  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segment  . 

*/ 

memcpy( temp ,( (char  *) segment  +  SEMJEROFFSET  +  4), 

♦((long  *)scgment  +  WSEbDEROFFSET) )  ; 

/♦  broadcast  the  data  through  the  socket  */ 

nbytes  =  sendto(  socket,  temp,  *((long  *)segment  +  VSEMJEROFFSET) ,  0, 

(struct  sockaddr  *  )&ne twork ,  a i zeof ( ne I  work )  ); 

if(nbytes  <=  0  I  I  nbytes  !=  ♦((long  *)segment  +  NNSEbDEROFFSET) ) 

/* 

This  error  indicates  the  socket  is  broken.  Just  exit  the 
sender  process. 

*/ 

perror( "wri te" ) ; 

pr  int  f  (  "VRITE_SOCKET_FRCM_SE<^ENT:  number  of  bytes  written  *  %d\n  "  .nbytes  ) ; 

print  f(  "Number  of  bytes  in  shared  segment  =  %d\n"  ,  *(  ( long  ♦)segment  +  VSEbOBROFFSBT) ) ; 

shutdown!  socket,  2  ); 

close)  socket  ); 

exi t( 1 ) ; 


/♦  free  the  sender  segment  */ 
free_sender( segment  )  ; 


supportc 

/*  the  following  routine  deletes  the  lender  by  writing 
a  negative  byte  count  into  the  ihared  aegment 
and  then  waking  up  the  sender. 


ki I l_sende  r ( segment , sendsem) 

char  'segment;  /*  ptr  to  the  segment  */ 

int  sendsem;  /*  semaphore  to  the  sender  */ 

I 


/*  write  a  negative  number  into  the  byte  count  field.  */ 

•((long  •)  segment  +  WSENDEROFFSET)  ■>  *1; 

/♦  at  this  point,  we  should  send  a  wakeup  to  the  sender  program, 
the  sender  will  read  the  bad  byte  count  and  exit. 

'/ 

V( sendsem)  ; 

I 


/*  the  following  routine  deletes  the  receiver  by  writing 
a  negative  byte  count  into  the  shared  segment 
and  then  waking  up  the  receiver. 


■/ 


kill_receiver( segment .receivesem) 

char  'segment;  /*  ptr  to  the  segment  */ 

int  receivesem;  /*  semaphore  to  the  receiver  */ 


/*  we  do  not  wait  until  the  receiver  segment  is  free  here 
as  the  process  that  calls  this  routine  should  already 
have  read  the  last  piece  of  data. 

*/ 


/*  write  a  negative  number  into  the  byte  count  field.  '/ 
'((long  *) segment  +  ARRECEIVEROFFSET )  =  -1; 


/*  at  this  point,  we  should  send  a  wakeup  to  the  receiver  program, 
the  receiver  will  read  the  bad  byte  count  and  exit. 

'/ 

V(  rece ivesem) ; 
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APPENDIX  B  -  'll  EXPLORER  MODULE  DESCRIPTIONS 


All  functions,  methods,  and  flavor  are  contained  in  file  irisflavor.llsp. 


1.  Calling  Protocols 


The  module  contains  functions,  methods,  and  a  flavor  that  are  intended  for  the 


application’s  use.  It  also  contains  a  macro  and  functions  that  are  used  internally.  The 


parameters  for  externally  accessible  functions  and  methods  are  described  below. 


a.  iris 


(defun  iris  (x)  ;where  x  is  nianber  of  iris  machine  desired 

b.  start-iris 


(defmethod  ( conve r sa t ion-wi t h- i r i s  :start-iris) 

() 


c.  get-iris 


(defmethod  ( conversat ion-wi th- i r i s  :get-iris) 

() 


mt-tris 


(defmethod  ( conve r sa t i on -wi t h- i r i s  .put-iris) 

(obj  ec  t ) 

(let*  ((buffer  (cond 

((equal  (type-of  object)  ’bignum)  ( conver t -number  -  to- • t r ing  object)) 

((equal  (type-of  object)  ’fixnum)  (conver t -number- to- s t r ing  object)) 
((equal  (type-of  object)  ’float)  ( conver t -number - 1 o- « t r ing  object)) 
((equal  (type-of  object)  ’string)  object) 

(t  ’’error" )  )) 


e.  stop-iris 


(defmethod  ( conver sa t ion-wi th- i r i s  :stop-iris) 

() 


f.  reuse-iris 


(defmethod  (conversat ion-wi th- i ris  :reuse-iris) 

() 
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2.  Code  and  Description 

(defmacro  loopfor  (var  init  teat  expl  Aoptional  exp 2  exp 3  exp4  expS) 

‘(prog  () 

( aetq  , var  ,  ini  I ) 

tag 

.expl 

I  ,exp2 

j  ,exp3 

!  ,  exp4 

,exp5 

(aetq  ,var  (1+  ,var)) 

:  (if  (=  , va r  .teat)  (return  t)  (go  tag))  )  ) 

(defun  conver t -number- t o- a t r ing  (n) 

(pr inc - to- a t r ing  n)  ) 

(defun  conve r t - a t r ing- 1 o- i n t eger  (atr  Aoptional  (radix  10)) 

(do  ((j  0  (+  j  1)) 

I  (n  0  (+  (*  n  radix)  ( d i gi t - char -p  (char  atr  j)  radix)))  ) 

((=  j  (length  atr))  n)  )  ) 

(defun  f ind-per iod- index  (atr) 

(catch  ‘exit 

(do  time  a  (x  (length  atr)  nil) 

(if  (equal  (char  atr  x)  (char  "  . "  0)) 

(throw  ’exit  x)  )  )  )  ) 

(defun  ge t - 1  of t a i de -of - rea 1  (atr  Aoptional  (radix  10)) 

(do  ((j  0  (1+  j)) 

(n  0  (+  (*  n  radix)  (di gi t -char -p  (char  atr  j)  radix)))  ) 

((or  (null  (digi t -char -p  (char  atr  j)  radix))  (=  j  (length  atr)))  n)  )  ) 

(defun  get-rightaide-of-real  ( a t r  Aop t i ona 1  (radix  10)) 

(do  ((index  (1+  ( f ind- per i od- index  atr))  (1+  index)) 

(factor  0.10  (*  factor  0.10)) 

(n  0.0  (+  n  (*  factor  (dig i t -char-p  (char  atr  index)  radix))))  ) 

( (=  index  (length  atr))  n)  )  ) 

(defun  convert  -  at  ring- to- real  (atr  Aoptional  (radix  10)) 

(+  (float  (ge t - lef t a ide -of  -  real  atr  radix))  (get-rightaide-of-real  atr  radix))  ) 


(defvar  * t cp- hand  1 e r 1*  (aend  i p : : * t cp- hand  I  e r *  :get-port)) 

(defvar  * tcp-handler2*  (aend  i p : : * t cp - handl e r*  :gel-port)) 

(defvar  * i r i a  1 -por 1 1  *  1027)  ;  thia  ia  the  aend  port 

(defvar  * i r i a  1 -por 1 2*  1026)  ;  thia  ia  the  receive  port 

(defvar  * i r i a  1  - addrea a*  3221866502) 

(defvar  * i r i a2 - add rea a  *  3221866504) 

(defvar  * i r i a3 - addrea a*  3221866505) 

(defvar  *de a t - addre a  a  *  nil)  ;  the  tcp-ip  or  internet  addresa 

;  look  in  network  configuration 


(defun  iria  (x) 

(cond  ((equal  x  1)  (aetq  *de a t - addre a  a  *  * i r i a  1  - addre a  a* ) ) 
((equal  x  3)  (aetq  *dest -address*  *i ri *3  -  address*) ) 

(t  (aetq  *de a t - add r e a  a  *  * i r i »2 - addre a  a* ) )  )  ) 


(defflavor  converaat ion-wi th- i ri a  ( ( t a  Ik i ng-por t -number  * i r i a  1 -por 1 1  * ) 

(listening -port -numbe  r  *irisl-port2*) 
(talking-port  *tcp-handlerl*) 

( 1 i a t en i ng-por t  *tcp-handler2*) 

(deatination  *de a t - addre a  a* )  ) 
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:  ge  t  table-instance-variables 
:settable-insl ance - va t i abl e a 
: ini t ab (e- ina l ance - var i abl ea  ) 

(defmethod  (converaat ion-wi  Ih- i ri a  :start-iris) 

() 

(progn 

(send  talking-port  :open 
.-active 

talking- port -numbe r 
destination 


30  ) 

(send  listening-port  topen 
: ac  t i ve 

I i steninp-port - numbe  r 
destination 
30  ) 

’"A  conversation  with  the  iris  machine  has  been  established”  >  ) 


tcp  will  begin  the  procedure  to  establish 
connection  (default  vs  :passive) 
port  number  of  destination  host 
machine  name  or  address  if  blank  and 
in  :passive  mode  local  machine  waits  for 
connect i on 

set  max  seconds  before  read  request  times  out 
;  :  pa  s  s i ve 


(defmethod  ( con ver sa t i on -wi  t h  -  i r i s  :reuse-iris) 

() 

(setq  *tcp-handlerl*  (send  i p ::* t cp - handl e r*  :get-port) 

*tcp-handler2*  (send  ip : : *tcp-handler*  :get-port) 
talking-port  * t cp-hand I e r 1  * 

I i s t ening-por t  * t cp -handl e r 2*  )  ) 

(defmethod  ( conve r s a t i on -wi  t h - i r i s  :get-iris) 

() 

(let*  ((typebuffer  "  ") 

( lengthbuf fer  ”  ”) 

(buffer  "  ") 

(buf fe r - length  1)  ) 

(progn 

(send  listening-port  ireceive 
typebuffer 
bu  f  f er - 1  eng t h 
30 

.-wait  ) 

(send  listening-port  :receive 
lengthbuf fer 
4 

30 

:  wa  i  t  ) 

(setq  bu f f e r -  1  eng t h  ( conve r t - s t r i ng- 1 o- in t ege r  1 engthbuf f e r ) ) 

(setq  buffer  (make-string  bu f f e r - 1  eng t h  :  in i t  i  a  1  -  elemen t  (character  32))) 
(send  listening-port  :receive 
buf  fer 

buffer-  length 
30 

:  wa  i  t  ) 

(cond  ((equal  typebuffer  "I")  ( conve r t - s t r i ng - t o - i n I ege r  buffer)) 

((equal  typebuffer  "R" )  (conve r t - s t r i ng- to- rea 1  buffer)) 

((equal  typebuffer  ”C" )  buffer) 

(t  nil)  )  )  )  ) 

(defmethod  ( conve r s a t i on -wi  t h  -  i r i s  :put-iris) 

( obj  ec  t ) 

(let*  ((buffer  ( cond 

((equal  (type-of  object)  ’bignum)  ( conve r t -numbe r - t o- s t r i ng  object)) 

((equal  (type-of  object)  'fixnum)  ( con ve r t - numbe r - l o- s t r i ng  object)) 
((equal  (type-of  object)  ’float)  ( conve r t - numbe r - t o- s t r i ng  object)) 
((equal  (type-of  object)  ’string)  object) 

(t  ’'error”)  )) 

(buf fer - length  (length  buffer)) 
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(typebuffer  (cond  ((equal  (tyjpe-of  object)  ’bignum)  "I") 

((equal  (type-of  object)  ’fixnum)  "  I" ) 

((equal  (type-of  object)  ’float)  ”R") 

((equal  (type-of  object)  ’itring)  "C” ) 

(t  *C")  )) 

( lengthbuf fer  ( conve r t - number - 1 o - a t r ing  buffer- length) ) 

(♦loopvariable*  0)  ) 

(progn 

(send  talking-port  .'send 
typebuffer 
1 

ni  1 
nil  ) 

(if  (=>  (length  1  eng  t  hbuf  f  e  r  )  4) 

(send  talking-port  :send 
lengthbuf f ?r 
4 

ni  1 
nil  ) 

(progn 

(loopfor  ’loopvariable*  (length  lengthbuf fer)  4 

(send  talking-port  :  send  "0”  1  nil  nil)  ) 

(send  talking-port  :send  lengthbuffer  (length  1  eng thbuf f e r )  nil  nil)  )  ) 
(send  talking-port  : send 
buffer 

buffer-  length 
t 

nil  )  )  )  ) 

(defmethod  ( conve r s a t i on-wi  t h  -  i  r  i  8  :stop-iris) 

(progn  (send  talking-port  -.close)  (send  1  i  s  t  eni  ng-por  t  tclose))  ) 


t 
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APPENDIX  C  -  SYMBOLICS  MODULE  DESCRIPTIONS 


All  functions,  methods,  and  flavor  are  contained  in  file  irisfiavor.lisp. 


1 .  Calling  Protocols 

The  module  contains  functions,  methods,  and  a  flavor  that  are  intended  for  the 


application’s  use.  It  also  contains  a  macro  and  functions  that  are  used  internally.  The 
parameters  for  externally  accessible  functions  and  methods  are  described  below. 

a.  select-host 

(defun  select-host  (host-name) 

b.  start-iris 

(defmethod  (:start-iris  conversat i on-wi th- i r i s ) 

() 

c.  get- iris 

(defmethod  (:get-iris  conversat ion-wi t h- i r i s ) 

() 

d.  put- iris 

(defmethod  (:put-iria  conve r aa t i on -wi t h - i r i a ) 

( object  ) 

(let*  ((buffer  (cond 

((equal  (type-of  object)  'bignum)  ( conve r t -numbe r - t o- a t r i ng  object)) 

((equal  (type-of  object)  'fixnum)  ( conve r t - numbe r - 1 o - a t r i ng  object)) 
((equal  (type-of  object)  ’ 8 i ng I e - f 1 oa t )  ( conve r t -numbe r - t o- i t r i ng  object)) 
((equal  (type-of  object)  'atring)  object) 

(t  ’  error"  )  )) 

e.  stop-iris 

(defmethod  (:stop-iris  convers a t i on-wi th- i r i s ) 

O 

f.  reuse-iris 

(defmethod  (:reuse-iris  conve rs a t i on-wi th- i r i s ) 

() 
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2.  Code  and  Description 

;;;  Mode:  LISP;  Syntax:  Comnon - 1 i ap ;  Package:  USER 

;  handy  macro  to  have  in  the  send  message  farthur  down 

(defmacro  loopfor  (var  init  test  expl  Aoptional  exp2  exp3  exp4  exp5) 
•(prog  () 

(  se  t  q  ,var  ,init) 
tag 

,  expl 
•  exp2 

,exp3 
,  exp4 
,  exp5 

(setq  ,var  (  1  +  ,var)) 

(if  (=  ,var  .test)  (return  t)  (go  tag))  )  ) 


(defun  conver t -numbe r - t o- s t r ing  (n) 

(pr i nc - 1 o- s  t  r  i  ng  n )  ) 

(defun  conve r t - s t r i ng - t o - i n t ege r  (sir  ^optional  (radix  10)) 

(do  ( ( j  0  (+  j  it) 

(n  0  (+  (*  n  radix)  ( d i g i t - cha r -p  (char  str  j)  radix)))  ) 

( (=  j  ( length  sir))  n)  )  ) 

(defun  f ind-per iod- index  (str) 

(catch  'exit 

(dotimes  (x  (length  str)  nil) 

(if  (equal  (char  str  x)  (char  0)) 

(throw  'exit  x)  )  )  )  ) 

(defun  ge t -  1 e f t s i de -of - rea 1  (str  &optional  (radix  10)) 

(do  ( ( j  0  (  1+  j  )  ) 

(n  0  (+  (*  n  radix)  (di g i (- cha r -p  (char  str  j)  radix)))  ) 

((or  (null  (digi t -char-p  (char  str  j)  radix))  (=  j  (length  str)))  n)  )  ) 

(defun  ge t - r i gh t s ide -of - rea 1  (str  &optional  (radix  10)) 

(do  ((index  (1+  ( f i nd- pe r i od - i ndex  str))  (1+  index)) 

(factor  0.10  (*  factor  0.10)) 

(n  0.0  (+  n  (*  factor  ( d ig i t - cha r - p  (char  str  index)  radix))))  ) 

((=  index  (length  str))  n)  )  ) 

(defun  conve r t - s t r i ng - t o - rea 1  (str  Aoptional  (radix  10)) 

(+  (float  ( ge t -  1 e f t s ide -of - rea  1  str  radix))  ( ge t - r i gh t s i de - o f - rea  1  str  radix))  ) 


(defvar  *iris-porll*  1027) 

(defvar  *iris  port2*  1026) 

(defvar  *  1 oc a  1  - t a  1 k -por t *  1500) 
(defvar  *  I  oca  1  - 1 i s t en - por I  *  1501) 


this  is  the  send  po r t 
this  is  the  receive  port 
this  is  the  local  send  port 
this  is  the  local  receive  port 


(defflavor  con ve r s a t i on -wi t h - i r i s  ( ( t a  1 k i ng - por t - numbe r  * i r i s -por t 1  * ) 

(listening- port -number  *i r i s -por  t  2*  ) 
(local-talk-port -numbe  r  *  I oc a  1  - 1  a  1 k - por  t  * ) 

(local-listen- port- numbe r  *local-listen-port*) 

( t  a  1 k i ng - s  t ream) 

( 1 i a  t  en  t  ng- s  t  ream) 

(dest inat ion-host -object )  ) 

(  ) 

: i n i t ab 1 e - i n s t ance - v a r  i  ab  1  e s  ) 

(defmethod  ( : i n i t - de s t i na t i on - hos t  conve r s a t i on -wi t h - i r i s ) 

( name  -  of -host ) 

(setf  dest inat ion-host -object  ( ne t : pa r se - hos t  name  -  of - hos t ) )  ) 
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(defmethod  (:atart-iris  con ve r sa t i on -wi t h - i r i a ) 

(  ) 

(setf  t a  1 k i ng  -  a t ream 

( I cp : open - 1  cp- s  t  ream  deatinati on -host- object 
talking- port- nimbe  r 
1  oca  1  - 1 a tk-por t -numbe r  )  ) 

(aetf  I i a t eni ng - a t ream 

( t  c p : open  - t  cp -  a  t  r e  am  deatinati on -hoat -object 
1 i a  t ening -por  t -numbe  r 
1  oca  1  -  1 i a t en-por t -numbe r  )  ) 

"A  conversation  with  the  iria  machine  has  been  eatabliahed"  ) 

(defmethod  (:reuae-iris  conve r a  a t ion -wi t h - i r i a ) 

(  ) 

) 

(defun  read-string  (stream  num-chara) 

(let  ( (out  -  at  ring  ) 

(dotimes  (i  num-chara) 

(setf  out-string  ( a t r i ng - append  out-atring  (read-char  stream)))  ) 
ou  t -  a  t  r i ng  )  ) 

(defmethod  (‘.get-iris  con  ve  r  s  a  t  i  on -wi  t  h  -  i  r  i  a  ) 

(  ) 

(let*  ( ( t  ypebuf  f  e  r  "  "  ) 

(  lengthbuf  fer  "  " ) 

(buffer  "  ”) 

(buffer-length  1)  ) 

(progn 

(setf  t  ypebuf  fer 

(read-string  I i a t en i ng - s t ream  1)  ) 

(setf  lengthbuffer 

(read-string  I i s t en i ng - a t r earn  4)  ) 

(setf  buffer-length 

( conve r t - s t r i ng- t o- i n t ege r  lengthbuffer)  ) 

(aetf  buffer 

(read-string  1 i s t en i ng - a t r e  am  bu f f e r  - 1  eng t h  )  ) 

(cond  ((equal  typebuffer  "I”)  ( c on ve r t - a t r i ng - t o - i n t ege r  buffer)) 

((equal  typebuffer  ”R" )  ( conve r t - a t r i ng - 1 o- r ea 1  buffer)) 

((equal  typebuffer  "C" )  buffer) 

(toil))))) 

(defvar  *atep-var*  0) 

(defun  my-wr i t e - a t r ing( a t r ing  stream) 

(lef*  ((num-chars  (length  string))) 

(dotimes  (i  num-chara) 

(write-char  (aref  string  i)  stream)  )  )  ) 

(defmethod  (:put-iris  conve r a  a t i on - wi t h - i r i a ) 

(object  ) 

(let*  ((buffer  (cond 

((equal  (type-of  object)  ’bignum)  ( conve r t -numbe r - t o - a t r i ng  object)) 

((equal  (type-of  object)  ’fixnum)  ( conve r t - numbe r - t o- a t r i ng  object)) 
((equal  (type-of  object)  ’ s i ng  1  e - f 1 oa t  )  ( conve r t - numbe r - 1 o- a t r i ng  object)) 
((equal  (type-of  object)  'string)  object) 

(t  ''error")  )) 

( bu f f e r - I  eng t h  (length  buffer)) 

(typebuffer  (cond  ((equal  (type-of  object)  ’bignum)  "I") 

((equal  (type-of  object)  ’fixnum)  "I") 

((equal  (type-of  object)  ’  a i n|  I  e - f I oa t )  ”R" ) 

((equal  (type-of  object)  ’string)  "C" ) 

(  t  ’’C"  )  )  ) 

(lengthbuffer  ( conve r t -numbe r - t o - a  l  r  i  ng  bu f f e r -  1  eng t h  ) )  ) 
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i 

i 


(progn 

(my -wr  i t e - a t r ing  typebuffer  t a Iki ng- 1 1 ream) 
(send  talking-stream  : f o rce - ou tpu t ) 

(if  (=  (length  I  eng t hbu f f e r  )  4) 

(wr i te- a t ring  lengthbuffer  talking- a t ream) 
n 

(loopfor  *atep-var*  (length  lengthbuffer) 
(wr i t e- a t r ing  "0"  t a  Ik i ng- a t r earn)  ) 


(profit 


(my -wr  i t e  -  a t r i ng  lengthbuffer  talking- at  ream) 
(send  t a  Iking- a t ream  :  force -output ) 

(my -wr  i tc  •  a t r ing  buffer  t alking- a t ream) 

(send  t alking- s t ream  : force -output )  )  )  ) 


)  ) 


(defmethod  (:stop-iria  conve r a  a t ion -wi t h - i r i a ) 
(  ) 

(progn  (send  > a  I  king- s t ream  :close) 

(send  1 i a t en ing - s t ream  :close)  )  ) 


(defun  select-host  (host-name) 

(send  talk  : i ni t -des t i na t i on - hos t  host-name)  ) 


* 


* 

! 

i 


i 

\ 
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APPENDIX  D  -  TEST  AND  UTILITY  PROGRAMS 


I.  gprog.c 

a.  Calling  Protocols 

This  is  a  test  program  for  the  direct  connect  protocol.  By  command  line 
argument,  another  machine  to  receive  direct  connect  messages  from  can  be  specified. 
The  default  is  to  receive  messages  from  irisl.  It  must  be  run  in  conjunction  with 
gprog2.c  to  function  properly,  as  the  port  assignments  are  hardcoded.  Since  it  is  the 
server  program,  it  must  be  started  before  gprog2.c. 

b.  Code  and  Description 

/*  this  is  file  gprog.c 

It  is  a  sample  top  level  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 

This  is  the  SERVER  side  program  and  runs  first  I  I  I . 

*/ 

#include  "shared. h" 

#inc 1 ude  "gl . h" 

#include  "device. h" 


ma  i n( argc , argv ) 

int  argc;  /*  argument  count  */ 

char  *argv[];  /*  pointers  to  the  passed  in  arguments  */ 


Machine  r emot  emach  i  ne  ; 
char  other_machine[50] ; 
char  mybuf fer [LARGESTREAD] ; 
char  ou  t  going  [LARGESTREAD] ; 


/♦  structure  for  remote  machine  */ 
/*  name  of  other  machine  */ 

/*  received  data  */ 

I*  outgoing  message’s  buffer  */ 


int  mybuf  fer  l  [IARGESTREAD /INTEGER,  SIZE] 
int  ou  tgoi  ng  1  [  LARGELY  1  READ  /  INTEGER,  S I ZE ) 
float  mybuf  f  e  r  2  [LARGESTREAD /FLOAT,  S I  ZE  ] 
float  outgoing2[LARGESTREAD/FLQAT_SIZE] 


/*  received  integer  data  */ 

/*  outgoing  integer  message's  buffer 

/*  received  float  data  */ 

/*  outgoing  float  message  buffer  *1 


1 o ng  nou  t  go i ng ; 


/*  size  of  the  outgoing  message  */ 


141 


-Y’V'V 


■y 

tj-V. 


gprog.c 

/*  temp  array  uied  to  make  outgoing  message  */ 
/*  menage  counter  */ 


1 

I 

j  chart  emp [10]; 

i 

long  count  =  0; 
char  recei ved_type( ) ; 
char  type_received; 

i 

1  int  elements  received; 

i  - 

|  long  i;  /*  temp  loop  variable  */ 

long  j  =  0;  /*  variable  to  control  message  sending  */ 


I*  pull  out  the  string  from  the  argument  list  ♦/ 
i f ( argc  >  2) 

I 

pr int f ( "GPROG:  incorrect  argument  countl  use  gprog  <a I i a s>\n"  ) ; 
exi t ( 1 ) ; 

1 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 
i f (  argc  ==  2  ) 

( 

strcpy(  o t he r_mach i ne  ,  "npscs-"  ); 
it  real  (  o t he rmach i ne  ,  argv[l]  ); 

I 

else 

strcpy(  o t he r_mach i ne  ,  “ npsc s - i r i s 1”  ): 

/*  create  a  path  to  a  particular  machine  (irisl  default)  */ 

/*  the  first  argument  is  the  key  for  the  shared  memory  segment, 
the  second  argument  is  the  name  of  the  machine  to  connect  to. 
the  third  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fourth  argument  is  the  receiving  port  number  for  the  socket  to  use. 
the  fifth  argument  indicates  whether  the  processes  should 
act  as  a  server  or  a  client. 

the  sixth  argument  is  the  returned  pointer  to  the  structure 
remot  emach  i  ne  . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sendsem  id, 
and  the  returned  receivesem  id. 

the  seventh  argument  is  the  amount  of  freespace  desired  for  dynamic 
memory  allocation  during  execution  of  the  program. 

dynamicmach  i  nepa t h(  1 , other  _ntach ine, 1 ,2, "server" ,&remot  emach  i ne , 2000000) ; 


/*  the  loop  for  polling  the  shared  segment  */ 
while (TRUE ) 

( 

/*  make  an  outgoing  message  */ 
st  rcpy(outgoing, "QrROG  ORIGINATED  NESSAOE:  "); 

count  *  count  -  1 ; 

ou t go i ng 1 [ 0 )  =  count; 

noutgoing  =  s t r 1 en ( ou t go i ng ) ; 

outgoing2[0]  =  count; 


/*  is  there  data  in  the  shared  se  g  me  n  t  ?  * / 
if(receiver_has_data(&r  emot emach ine)) 

( 

type_rece i ved  =»  rec e i ved_ t ype (&r emo t emach i ne ) ; 
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printf("The  message  received  by  OHROQ  ia  of  type  %c  \n", 
type_recelved) ; 

switch  ( type_received) 

*  case  CHARACTER_ARRAY_TYPE : 

element s_received  =  numbe r_r ece i ved(Ar emot emachi ne ) ; 

printf("The  message  received  by  GPROG  is  %d  elements  longl\n”, 
element  s_recei ved) ; 

read_characters(Aremotemachine ,  mybuffer,  elements_received) ; 
break ; 

case  INTEGER_TYPE : 

read_ integer (&r emo t emachi ne  ,mybuf  f e r  1 ) ; 
break ; 

case  FLQAT_TYPE : 

read_f 1 oa  t (Ar  emot  emachine  ,mybuf f er2)  ; 
b  r  e  ak ; 

/*  at  this  point  in  the  program,  process  the  received  data.,.*/ 
pr in t f ( "GPROG  has  received  the  following  data:\n”); 


has  received  the  following  data:\n”); 


switch  ( type_received) 

(  case  CHARACTER, ARRAY„TYPE : 

for(i=0;  i  <  element s_receivcd;  i+=l) 

pr in t  f ( "%c" .mybuf  f er [ i ] ) ; 

I 

break ; 

case  INTEGER,TYPE : 

pr in t  f ( "%d"  .mybuf  fe r 1 [ 0 } ) ; 
break ; 

case  FLOATTYPE: 

pr in t  f ( "%f  " .mybuf  fe  r2[0] ) ; 
break ; 

) 

pr i n t  f ( ”\n" ) ; 

I 

/*  at  this  point,  we  would  look  at  our  system  and  see  If  we  needed 
to  send  data.  Instead,  I  wilt  check  if  the  sender  is  free. 

If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 
i f ( sender_i s  f ree(Aremo t emach i ne ) ) 

I 

i  f  ( ( j  %  3  )  ==  0 ) 

write_characters (Ar emot  emach ine , ou t  go i ng , nou  t goi  ng ) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  I sende r_i s_f ree(Aremot  emachine )  )  /*  do  nothing  */  ! 

i f ( ( j  %  3)  ==  1) 

wri te_integer(Ar  emot  emach ine , outgoingl )  ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  !  aender_i a_f ree(Aremot emachine )  )  /*  do  nothing  */  ; 

i f ( ( j  %  3)  =*  2) 

wr  i  t  e_f  loa  t (Ar emot  emach  i ne , ou  t  going2 ) ; 
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/*  assume  socket  connection  broken  */ 
print f("Sender  wasn’ t  freel  Te rmi na t i ng . . . \n  ); 
break; 

)  /*  endif  while  TRUE  */ 

/•  get  rid  of  the  path  to  the  other  machine...*/ 

deletemachinepath(iremotemachine) ; 


II 


) 


2.  gprog2.c 


a.  Calling  Protocols 

This  is  a  test  program  for  the  direct  connect  protocol.  By  command  line 
argument,  another  machine  to  receive  direct  connect  messages  from  can  be  specified. 
The  default  is  to  receive  messages  from  irisJ.  It  must  be  run  in  conjunction  with 
gprog.c  to  function  properly,  as  the  port  assignments  are  hardcoded.  Since  it  is  the 
client  program,  it  be  started  after  gprog.c  is  ready  for  it. 

b.  Code  and  Description 

/♦  this  is  file  gprog2.c 

It  is  a  sample  top  level  graphics  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  snared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 

This  is  the  CLIENT  side  program  and  runs  second!!!. 

*/ 

#include  "shared. h" 

#de  f i ne  TRUE  1 


main) argc , argv ) 

int  argc;  /*  argument  count  */ 

char  *argv[];  /*  pointers  to  the  passed  in  arguments  */ 


Machine  r emo t emach i ne ; 
char  other_machine[50]  ; 
char  mybuf  f  e  r  [LAROESTREAD]  ; 
char  outgoing! LAROESTREAD ] ; 


/*  structure  for  remote  machine  */ 
I*  name  of  other  machine  */ 

/*  received  data  */ 

/*  outgoing  message’s  buffer  */ 


int  mybuf f e r 1 [ LAROESTREAD/ INTEQER_S  IZE] ;  /*  received  integer  data  */ 

int  ou  t goi ngl [LAROESTREAD/ INTEGER_SIZE] ;  /*  outgoing  integer  message’s  buffer  */ 

float  mybuf fer2 [LAROESTREAD /FLOAT, SIZE] ;  /*  received  float  data  */ 

float  ou t go ing2 [LARGEST  1READ/FLQAT_S IZE] ;  /*  outgoing  float  message  buffer  ♦/ 

long  noutgoing;  /*  size  of  the  outgoing  message  */ 

char  temp[ 10];  /*  temp  array  used  to  make  outgoing  message  */ 

long  count  =  0;  /*  message  counter  *1 

char  rece i ved_ t ype ( ) ; 
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char  type_received; 
int  e lemen t a_rece i ved; 

long  i;  /*  temp  loop  variable  */ 

long  j  =  0;  /*  variable  to  control  message  sending  */ 


/♦  pull  out  the  string  from  the  argument  list  */ 
i f ( argc  >  2) 

( 

pr int f ( "GPROG2 :  incorrect  argument  count!  use  gprog2  <a 1 i a s>\n " ) ; 
exit(l); 

I 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 
if(  argc  ==  2  ) 

I 

strcpy(  o t he r_mach i ne  ,  "npscs-"  ); 
strcatf  other_machine ,  argv[l]  ); 

I 

else 

strcpy(  o t he r_mach i ne  ,  " np sc s - i r i s2"  ); 


/*  create  a  path  to  a  particular  machine  (  i  r i a  2  default)  */ 

/*  the  first  argument  is  the  key  for  the  shared  memory  segment, 
the  second  argument  is  the  name  of  the  machine  to  connect  to. 
the  third  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fourth  argument  is  the  receiving  port  number  for  the  socket  to  use. 
the  fifth  argument  indicates  whether  the  processes  should 
act  as  a  server  or  a  client. 

the  sixth  argument  is  the  returned  pointer  to  the  structure 
remot  emach  ine  . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sendsem  id, 
and  tne  returned  receivesem  id. 

*/ 

mach i nepa  t  h(  1, o  ther_mach ine, 2,1, "client" .Aremot  emach ine) ; 

/*  the  display  loop  and  loop  for  polling  the  shared  segment  */ 
whi le(TRUE) 

{ 

/*  make  an  outgoing  message  */ 

s t rcpy ( ou t go i ng , "GPROG2  ORIGINATED  NGSSAGE:  ”); 

count  =  coun  t  +  1 ; 

oulgoinglfO]  =  count; 

noutgoing  =  s t r 1 en( ou t go i ng ) ; 

outgoing2[0J  =  count; 


/  *  is  there  data  in  the  shared  se  gme  n  t  ?  * / 
if(receiver_has_dat  a (Aremot  emach i ne ) ) 

I 

t ype_rece i ved  =  r ece i ved_ t ype (Aremo t emach i ne ) ; 

printf("The  message  received  by  GPR0G2  is  of  type  %c  \n" , 
type_received) ; 

switch  ( t ype_ r ec e i ved  ) 

I 

case  CHARACTER, ARRAY_TYPE : 

e I  emen t s_rece i ved  =  nianbe r_r ece i ved  (Aremo t  emach  i  ne )  ; 
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prinlf("The  message  received  by  GPR0G2  is  %d  elements  longl\n", 
e lemen t s.receivea); 

r ead.cha  r  ac t  e  r  s (Arono t  emach i ne ,mybuf f e  r , 
elements. received) ; 

break; 

case  INTEGER_TYPE : 

read. in t  eger (Aremot  ema  chine ,mybuf  f er 1 ) ; 
break; 

case  FLQVT.TYPE: 

read. float (Aremot emach i ne .mybuf fer2) ; 
break; 

I 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 
p r  i  n t f ( "GPRDG2  has  received  the  following  data:\n”); 

switch  ( type.rece ived ) 

I 

case  CHARACTER.ARRAY.TYPE : 

for(i=0;  i  <  elements  received;  i+=l) 

( 

pr in t  f  (  "%c"  ,mybu  f  f er [ i ] ) ; 

) 

break; 

case  INTEGER.TYPE : 

pr in  t  f ( "%d" , mybuf  f er 1 [0] ) ; 
break; 

case  FLOATTYPE: 

pr in t  f ( "%f " , mybuf  fer2[0] ) ; 
break; 

) 

printf ("\n" ) ; 

I 

/*  at  this  point,  we  would  look  at  our  system  and  sec  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 

If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 
if(sender_i  s_f  ree  (Arenio  t  emach  i  ne  ) ) 

if((j  %  3)  ==  0) 

write  characters'*;-  *'“'•*  emach  i  ne,  outgoing,  nout  going); 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  I sender.i s.f ree(&remot emach i ne )  )  /*  do  nothing  */  printf("2"); 

if((j  %  3)  ==  1) 

wr i t  e.in  t  eger  (Aremot emach i ne , ou t go ingl ) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  I sende r.i s.f ree(Aremo t emachi ne )  )  /*  do  nothing  */  printf("3"); 

if ( ( j  %  3)  ==  2) 

wr  i  t  e.f loa t  (Aremot  emach i ne .out  going2  ) ; 


++j  ; 

I 

else 


I 

/*  assume  socket  connection  broken  */ 
pr i nt f ( "Sende r  wasn’t  free!  Terminat ing . . . \n" ) ; 
break ; 
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/*  at  this  point,  you  can  do  the  rest  of  the  display  loop  */ 
|  /*  endif  while  TRUE  */ 

/*  get  rid  of  the  path  to  the  other  machine...*/ 
deletemachinepathl&remotemachine) ; 


s 
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a.  Calling  Protocols 

This  is  a  test  program  for  the  broadcast  protocol.  By  command  line  argument, 
another  machine  to  receive  broadcast  messages  from  can  be  specified.  The  default  is  to 
receive  messages  from  iris2.  It  must  be  run  in  conjunction  with  prog2.c  to  function 
properly,  as  the  port  assignments  are  hardcoded. 

b.  Code  and  Description 

/*  this  is  file  prog.c 

It  is  a  sample  top  level  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 


*/ 

#include  "shared. h" 
#define  TRUE  1 


main( argc , argv) 

int  argc;  /*  argument  count  */ 

char  *argv[J;  /*  pointers  to  the  passed  in  arguments  ♦/ 


Machine  remotemachinel ; 
Machine  remotemachine2; 
char  other_machine[50] ; 
char  mybuf  fer  [LARGESTREADJ  ; 
char  out  going  [LAROESTREAD] ; 


/*  first  structure  for  remote  machine  ♦/ 

/*  second  structure  for  remote  machine  */ 

/•  name  of  other  machine  */ 

/*  received  data  */ 

/*  outgoing  message’s  buffer  */ 
int  mybuf fer 1 [LAROESTREAD/ INTEGER_SIZE] ;  /*  received  integer  data  */ 
int  out  going!  [LAROESTREAD/ INTEGER.SIZEJ;  /*  outgoing  integer  message's  buffer  */ 
float  mybu f f e r  2  [LARGEST  READ/ FLGAT_S  IZE  ] ;  /*  received  float  data  */ 
float  ou t go i ng2 [LAROESTREAD/ FLCIAT_S I ZE] ;  /*  outgoing  float  message  buffer  */ 


long  noutgoing; 
char  t  emp  [10]; 
long  count  =  0; 
char  received_type( )  ; 
char  t ype_rec e i ved ; 


I*  size  of  the  outgoing  message  */ 

/*  temp  array  used  to  make  outgoing  message  */ 
/*  message  counter  */ 
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int  e 1  emen t s_r ece i ved ; 

long  i;  /*  temp  loop  variable  */ 

long  j  =  0;  /*  variable  to  control  message  sending  */ 


/*  pull  out  the  string  from  the  argument  list  */ 
i f ( a  rgc  >  2  ) 

I 

pr i nt f ( "PROG:  incorrect  argument  count!  use  prog  <alias>\n"); 
exi t (  1 )  ; 

) 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 
i f (  argc  ==  2  ) 

1 

strcpy(  o t he r_mach i ne  ,  argv[l]  ); 

1 

else 

strcpy(  o  t  he  r_mach  i  ne  ,  "  npsc  s  -  i  r  i  s  2"  ); 


/*  create  a  pair  of  paths  to  a  particular  machine  (iris2  default)  */ 

/*  the  first  argument  is  the  maximum  number  of  channels  to  be  created, 
the  second  argument  is  the  key  for  the  shared  memory  segment, 
the  third  argument  is  the  name  of  the  machine  to  connect  to. 
the  fourth  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fifth  argument  is  the  receiving  port  number  for  the  socket  to  use. 
the  sixth  argument  indicates  whether  the  processes  should 
act  as  a  receiver  or  a  broadcaster. 

the  seventh  argument  is  the  returned  pointer  to  the  structure 
r emot  emacli  i ne  1  or  reino t  emach  i  ne2  . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sends cm  id, 
and  the  returned  receivesent  id. 

*/ 

dy n  ami tmach inepaths(2, 1 ,o  t  he  r_mach i ne,2, 1 ."receive" ,&remo t  emach i ne 1 ) ; 
s 1 eep( 5 ) ;  /  *  to  let  both  sides  set  up  receiving  channels  first  *  / 

dynami  emach inepaths(2, 1 ,othe  r_mac  h ine, 4, 3, "broadcast" ,&r emot  emach i ne2 ) ; 


/*  the  loop  for  polling  the  shared  segment  limited  to  avoid  send  buffer 
overflow  *  / 

while (TRUE) 

I 

/*  make  an  outgoing  message  */ 
s t repy ( ou I  go i ug , "PROG  ORIGINATED  MESSAGE:  " ) ; 

count  =  count  +  1; 

outgoingl(O)  =  count; 

noutgoing  =  s t r I en( ou t go i ng ) ; 

outgoing2[0]  =  count; 


/*  is  there  data  in  the  shared  segment?  */ 
i f(receiver_has_data(&r  emo  t  emach i ne I ) ) 

( 

t ype_rece i ved  =  r ece i ved_ l ype (&r emo t emach i ne 1 ) ; 

printf("The  message  received  by  PROG  is  of  type  %c  \n 
1 ype_ received); 

switch  ( t ype_ r ec e i ved  ) 
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( 

case  CHARA.CTER_ARRAY_TYPE : 

elementa_received  =  numbe r.rece i ved(Aremo t emach ine 1 ) ; 

printf("The  message  received  by  PROD  is  %d  elements  long!\n", 
e I emen I s_ received) ; 

readcharac t  e  r s (Aremot  emach ine i  ,mybuf f er  , 
e 1 emen ts_ received) ; 

break; 

case  INTEUER.TYPE: 

read_integer(Aremot emachinel ,mybuf ferl) ; 
break ; 

case  FLOVT  I'Y  PE : 

read_f  I oa t  (Aremo t emach i nel  ,mybuf  f  er2) ; 
break ; 

I 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 
printf("PROO  has  received  the  following  data:\n”); 

switch  ( type_received) 

I 

case  CHARACTER_ARRAY_TYPB . 

for(i=0;  i  <  element s_received;  i+=l) 

( 

p  r i n  t  f ( "%c  " ,mybu  ffer[i]); 

) 

break ; 

case  I NTEOER_TYPE : 

pr in t  f (  "%d" ,mybuf  f er 1 [0] ) ; 
break ; 

case  FLQ\T_TYPE: 

pr  i  n t  f ( "%f  " .mybuf  f er2l0] ) ; 
break; 

) 

pr  int  f ("\n" ) ; 

I 

/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 

If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 
i f ( aender_i a  free  (Aremot  emach i ne2 ) ) 

I 

if((j  %  3)  ==  0) 

write  ..characters (Aremot  emach i ne 2 .outgoing ,nou  t  goi ng ) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  I sende r_i s_f ree (Aremot  emac h i ne2 )  )  /*  do  nothing  pr i n t f (  ”2”  )  * /  ; 


if((j  %  3)  ==  1) 

wr i t  e_in tege  r (Aremot  emach i ne 2 , ou t  goi ng 1 ) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  1 sender_i s_f ree(Aremot  emach i ne2 )  )  /*  do  nothing  pr in t f ( " 3" )* /  ; 

if((j  %  3)  ==  2) 

wr  i t  e_f loa t (Aremot  emach i ne2 , ou  t  go i ng2 ) ; 

/*  wait  until  message  sent  before  continuing  */ 

while(  I sender_i s_f ree (Aremot emach ine2 )  )  /*  do  nothing  pr i n t f ( "4"  ) * /  ; 

++j ; 

I 

else 


ISi 


/*  assume  socket  connection  broken  */ 
pr in t f ( "Sende r  wasn't  freel\n"); 
break; 

I 


/*  at  this  point,  you  can  do  the  rest  of 
|  /*  endif  while  TRUE  */ 

/*  get  rid  of  the  path  to  the  other  machine 
d  e  1  e  t  etna  chinepathf&r  emo  t  ema  c  h  i  n  e  1  )  ; 
de 1 e  t emach i nepa  t  h (&r  emo  t  emach  ine2  )  ; 


4.  prog2.c 
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a.  Calling  Protocols 

This  is  a  test  program  for  the  broadcast  protocol.  By  command  line  argument, 
another  machine  to  receive  broadcast  messages  from  can  be  specified.  The  default  is  to 
receive  messages  from  irisl.  It  must  be  run  in  conjunction  with  prog.c  to  function 
properly,  as  the  port  assignments  are  hardcoded. 

b.  Code  and  Description 

/*  this  is  file  prog2 . c 


It  is  a  sample  top  level  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 


p  * 

m 

Th  i  s  program 

*/ 

£ 

# i nc 1 ude  "shared 

V 

#define  TRUE  1 

•}> 

i 

ma i n( a  r gc , a  rgv  ) 

int  a  r gc  ; 
char  *a  rgv  [  ]  ; 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 


/*  argument  count  */ 


Machine  remot emach i ne 1 ; 
Machine  remo  t emach i ne2 ; 
char  o t he r_mach i ne [ 50 J ; 
char  mybu f  f  e  r  [LARGESTREAD]  ; 
char  ou  t  go i  ng [LARGESTREAD]  ; 


/*  first  structure  for  remote  machine  */ 
/*  second  structure  for  remote  machine  */ 
/*  name  of  other  machine  */ 

I*  received  data  * / 

/*  outgoing  message’s  buffer  */ 


int  mybuf fe r 1 [LARGESTREAD/ INTEGER_S1ZE] 1  /*  received  integer  data  */ 


int  out  go  ingl  [LARGESTREAD/ IMEGER^SIZE] 
float  mybuf fer2 [LARGESTREAD /FLOAT. SIZE] 
float  ou  t  go  i  ng2  [LARGESTREAD/FLQAT.S  IZE] 
long  noutgoing;  /*  size 

char  t  emp  [10];  / *  t  emp 

long  count  =  0;  /*  mess 

char  rec e i ved_ t  ype ( ) ; 
char  t ype.rece i ved ; 


RESIZE];  /*  outgoing  integer  message’s  buffer  */ 
T.SIZE];  /*  received  float  data  */ 

T.SIZE];  /*  outgoing  float  message  buffer  */ 

/*  size  of  the  outgoing  message  */ 

/*  temp  array  used  to  make  outgoing  message  */ 

/*  message  counter  */ 
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ini  el eme nt  s_received; 

long  i;  /*  temp  loop  variable  */ 

long  j  =  0;  /*  variable  to  control  message  sending  */ 


/*  pull  out  the  string  from  the  argument  list  */ 
i f ( a  rgc  >  2  ) 

I 

pr int f ( "PROG2 :  incorrect  argument  count!  use  gprog2  <alias>\n"); 
ex i t ( 1 )  ; 

I 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 
i f f  argc  ==  2  ) 

( 

strcpyl  other_machine ,  argvfl]  ); 

I 

else 

strcpy(  o t he r_mach  i  ne  ,  "npsc s - i r i s2”  ); 


/*  create  a  path  to  a  particular  machine  (iris2  default)  */ 

/*  the  first  argument  is  the  maximum  number  of  channels  to  be  created, 
the  second  argument  is  the  key  for  the  shared  memory  segment, 
the  third  argument  is  the  name  of  the  machine  to  connect  to. 
the  fourth  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fifth  argument  is  the  receiving  port  number  for  the  socket  to  use. 
the  sixth  argument  indicates  whether  the  processes  should 
act  as  a  server  or  a  client. 

the  seventh  argument  is  the  returned  pointer  to  the  structure 
r emo t emac h i ne 1  or  r emo t emac h i ne2 . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sendsem  id, 
and  the  returned  receivesem  id. 

*/ 

dyn  ami  emac  h i nepa  t  h  s ( 2 , 1 ,othe  r_mach ine, 3,4, "receive"  ,&remo t  emac  h  i  ne2 )  ; 

sleep(5);  /*  to  let  both  ends  of  the  process  get  set  up  */ 

dy nami  cmach i nepaths(2, 1 ,ot  he  r_mach i ne, 1,2, "broadcast” ,&r emo t  emach i ne 1 ) ; 


/*  the  display  loop  and  loop  for  polling  the  shared  segment  */ 
wh i  let  TRUE ) 

( 

/*  make  an  outgoing  message  */ 

strcpyl out  going, "PROG2  ORIGINATED  MESSAGE .  "); 

coun  t  =  coun  t  +  1 ; 

outgoinglfO)  =  count; 

noutgoing  =  s I r 1 enl ou t go i ng ) ; 

ou t go i ng2 f 0 ]  =  count; 


/  *  is  there  data  in  the  shared  se  gme  n I  7  * / 
i  f( recei ver_has_da! a (&r emo  t  emach i ne  2 ) ) 

( 

typereceived  =  r ece  i  ve d _ t y pe (&r emo t emac h i ne 2 ) ; 

print  ft  "The  message  received  by  PROG2  is  of  type  %c  \n" , 
t  ype_  rece i ved  )  ; 

switch  ( typereceived) 
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case  CHARACTER_ARRAY_TYPE: 

element s_received  =  numbe r.rece i ved(Aremo t  emach i ne2 ) ; 

printf("The  message  received  by  PR0G2  is  %d  elements  long!\n 
e 1 emen t  s_receivea) ; 

read.chati  ten (iremot emach i ne2  .mybuf  f e r , 
e  1  emer  ts_received) ; 

break ; 

case  I  NTEGER_TYPE : 

read_ integer (Aremo t  emach ine2  ,mybu f  f  e  r  1 ) ; 
break ; 

case  FLQAT_TYPE : 

read_f 1 oa t (Aremo  t  emach  i  ne2  .mybuf  f e  r2 ) ; 
break; 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 
p r i n t f ( "PROG2  has  received  the  following  data:\n"); 


32  has  received  the  following  data:\n"); 


switch  ( type_rece i ved) 

case  a lARACTER  ARRAY  TYPE : 

for(i=0;  i  <  e 1 emen t s_rece i ved ;  i+=l) 


pr  i  n  t  f ( "%c" .mybuf  f e  r [ i J ) ; 


break; 

case  INTEGERTYPE 

pr  i  n  t  f ( "%d" .mybuf  fe  r 1 10] ) ; 
break ; 

case  FLOATTYPE: 

pr  i  n  t  f ( "%f  " .rnybu f  f e  r 2 [0 J ) ; 
break; 

I 

p  r  i  n  t  f  (  "  \  n  "  ) ; 

I 

/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 

If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 
i f(sender_i s_free (Aremo  t  emach i ne 1 ) ) 

( 

i f ( ( j  %  3)  ==  0) 

wri te_characters (Aremo  t  emach inel , outgoing, noulgoing); 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
whi!e(  I  sender_i  s_f  ree  (Areniot  emach  i  lie  1  )  )  /*  do  nothing  pr  i  n  t  f  ( "  2"  )  *  / 

i  f ( ( j  %  3 )  ==  1 ) 

wri te^integer (&r emo t emach inel .outgoingl )  ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  I sende r _ i s_f ree ( Ar emot  emach i ne 1 )  )  /*  do  nothing  pr i n t f ( " 3"  )*  / 

i f ( ( j  %  3)  ==  2) 

writ e_ float (Aremo  t  emach i ne I  ,outgoing2); 

/♦  wait  until  message  sent  before  continuing  */ 

while!  I sende r  i s _f re e (Ar emo  t emach i ne 1  )  )  /*  do  nothing  pr i n t f ( "4"  )  *  / 


5.  rmshare.c 


a.  Calling  Protocols 

This  is  a  stand-alone  utility.  It  will  remove  all  shared  memory  segments  owned 
by  the  user.  By  command  line  argument,  selective  segments  can  be  removed. 

b.  Code  and  Description 


TITLE 

In  t  e  r -Compu  t  e  r  Cotnmun  i  c  a  1  i  on  Package 

M1XJLE  : 

rmsha  re  .  c 

VERSION: 

1.0 

DATE 

25  February  1988 

AUTHOR  : 

Theodore  H.  Barrow 

HISTORY: 

VERSION:  1.0 

DATE  :  25  February  1988 
AUTHOR  :  Theodore  H.  Barrow 

DESC.  :  Removes  shared  memory  segments  identified  on  command  line. 

RECORD  OF  CHANGES 

Version*  Date  *  Author  *  *  Affected  *Reqd 

*  Change  Description  *  Modules  *Vers 


Jr  ,<» 
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r  ms  hare 

#include  <errno.h> 

#include  <sy s / sy smac ros . h> 

#include  <stdio.h> 
ftinclude  <sy a / t ype s  .  h> 

#include  <sys/ipc.h> 

#include  <sys/sltm.h> 

#include  <gl . h> 

/*  The  following  defines  will  have  to  be  modified  for  different  machine 
but  one  of  tne  underlying  shared  memory  attachment  mechanisms  should 
work  for  any  system  V  implementation.  */ 

#de  f i ne  IRIS4D  1 
#de fine  IRIS3000  2 
# i f  d  e  f  FLAT 

#define  WVCHINE  IRIS4D 
#e  1  s  e 

#de fine  MACHINE  IRIS3000 
#end  i  f 

extern  int  errno; 
ma i n (  a  rgc  ,  a  rgv  ) 

int  argc;  /  *  a  r  g  time  n  t  count  *  / 

char  *argv[J;  /*  pointers  to  the  passed  in  arguments  */ 

I 

int  first  =  1; 
int  last  =  1000; 
key_  I  i  ; 
int  s  timid; 
key_t  key; 

static  struct  shmid_ds  buffer; 

/*  set  the  number  of  shared  memory  keys  to  remove  */ 
i f ( a rgc  >  1 ) 

! 

forf  i=first;  i<argc;  i++  ) 

key  =  a  t  o i (  a  rgv [ i ]  ) ; 

if(  (shmid  =  slimget(  key,  0,  0))  ==  -1  ) 

I 

iff  errno  1=  EM0ENT  ) 

I 

write_error(  shmid,  key,  errno  ); 

1 

I 

else 

( 

iff  shmctlf  shmid,  IPC_RMID,  Abuffer  )  ==  - 1  ) 

( 

write_error(  shmid,  key,  errno  ) ; 

I 

else 

write  dontl  shmid,  key  ); 

1  /*  iff  f shmid  =  shmgetf  i,  0,  0  ))  ==  -1  )*/ 

I  /»  for  */ 


forf  i  =  first;  i  < ■ a  s  t ;  i++  ) 

I 

iff  (shmid  =  shmgetf  i,  0,  0))  ==  -1  ) 

I 

iff  errno  1=  ENOENT  ) 

I 

write  errorf  shmid,  i,  errno  ); 
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I 

else 

if(  shmctl(  shmid,  IPC  RMID ,  Abuffer  )  ==  -1  ) 

I 

write_error(  shmid,  i,  errno  ); 

} 

else 

write_done(  shmid,  i  ); 

)  /*  if(  (shmid  =  shmget(  i,  0,  0  ))  ==  -1  )  */ 

I  /*  for  */ 

I 


printf(  "\nCompleted.\n"  ); 
)  /  *  ma  i  n  (  )  *  / 


write_error(  shmid,  key,  error  ) 
int  shmid; 
key_t  key; 
int  error; 


printf(  "\nShared  Memory  ID  %d  (key  %d)  caused  error  %d . " , 
shmt  d  ,  key ,  error  ) ; 

)  /*  wri te_error(  )  */ 


write_done(  shmid,  key  ) 
int  shmid; 
key_t  key; 


printf(  "\nShared  Memory  ID  %d  (key  %d)  removed.",  shmid,  key  ) 
)  /*  wr i te_done( )  */ 
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6.  testshare.c 


a.  Calling  Protocols 


This  is  a  stand-alone  utility.  It  will  print  current  parameters  for  all  active 
shared  memory  segments.  By  command  line  argument,  selective  segments  can  be 
printed. 

b.  Code  and  Description 

z^t*************************************************************************** 


TITLE 

MDULE 


VERSION 


Al/THOR 


In t e r -Compu t e r  Conrnun i ca t i on  Package 
testshare.c 


25  February  1988 
Theodore  H.  Barrow 


HISTORY: 


VERSION 


AUTHOR 


25  February  1988 

Theodore  H.  Barrow 


DESC.  :  Determines  which  shntid  values  are  used  and  what  their 
par  ame  t  e  r  s  are. 


RECORD  OF  CHANGES 

Version*  Date  *  Author  * 

*  Change  Description 


Affected  *Reqd 
Modules  *Ve r s 


A  .V  v  -.  i 


testshare.c 


#include  <errno.h> 

# i nc  1  ude  <sy s / sy snac ros  .  h> 
tinclude  <stdio.h> 

#include  <sy » / t ype § . h> 

#include  <sys/ipc.h> 

^include  <sys/shmh> 

# i nc 1 ude  <gl . h> 

/*  The  following  defines  will  have  to  be  modified  for  different  machines 
but  one  of  the  underlying  shared  memory  attachment  mechanisms  should 
work  for  any  system  V  implementation.  */ 

#de fine  IRIS4D  1 
#de fine  IRIS3000  2 
dfifdef  FLAT 

#define  MACHINE  IRIS4D 
#e  1  se 

#de  f  i  ne  MACHINE  IR1S3000 
#endi f 

extern  int  err no; 

ma  i n (  ) 

( 

int  first  =  1 ; 
int  last  =  1000 ; 
int  i  ; 
int  shmid; 

for(  i=first;  iclast;  i++  ) 

l 

i f (  (shmid  =  shmget(  i,  0,  0))  ==  '1  ) 

( 

if(  errno  1=  EN0ENT  ) 

( 

write_error(  shmid,  i,  errno  ); 

I 

I 

e  1  se 

( 

if(  wr i t e_s t rue t (  shmid  )  ==  - 1  ) 
write_error(  shmid.  i,  errno  ) ; 

|  /*  iff  (shmid  =  shmget(  i,  0,  0  ))  ==  -1  )  */ 

I  /*  for  */ 

printf(  " \nComp 1 e t ed . \n"  ); 

)  /  *  ma  i  n  (  )  *  / 


write_error(  shmid,  key,  error  ) 
int  shmid; 
key_t  key; 
int  error; 


printf(  "\nShared  Memory  ID  %d  (key  %d )  caused  error  %d . M , 
shmid,  key ,  error  ) ; 

)  / *  wr i t  e_e r  ror  (  )  *  / 


struct  shmid_ds  *get_struct(  shmid  ) 
int  shmid; 

t 

static  struct  shmid_ds  buffer; 

if(  shmctl(  shmid,  I PC  STAT ,  Abuffer  )  ==  -  1  ) 


testshare.c 
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i 

retum(  (struct  shmid_ds  *)-l  ); 

I 

else 

return(  &bu  f  f  e  r  ) ; 

I  /*  ge  t_8  t rue  t (  )  *  / 


wr i t e_s t rue t (  shmid  ) 
int  shmid; 


struct  shmid_ds  *buf ; 

if(  (int)(buf  =  get_struct(  shmid  )) 
re  turn!  (int  )buf  ) ; 


pr i n  t  f (  "\nSI 
printf(  "\n 
p r i n  t  f (  "\n 
print f(  "\n 
p r i n  t  f (  "\n 
pr  i  n  t  f (  "\n 
printf(  "\n 
pr i n  t  f (  "\n 
p r i n  t  f (  "\n 
p  r i n  t  f (  "\n 
pr  i  n  t  f (  " \n 
print  f(  "\n 
printf(  "\n 
print  f (  "\n 
print f(  "\n 
print f(  "\n 
p  r i n  t  f (  "\n 
printf(  "\n 

return!  0  )  ; 


"\nSha red  Memory  ID  9W  has  the  following  structure:",  shmid  ); 
"\n  shm_perm  has  the  following  structure:"  ); 

"\n  cuid  is  %d  . " ,  bu f ->shm_pe rm.  cu i d  ); 

"\n  cgid  is  %d  buf ->shm_pe rm. cgi d  ); 

"\n  uid  is  %d  . "  ,  bu f -> shm_pe rm.  u i d  ); 

"\n  gid  is  %d.",  buf ->shm_perm. gid  ); 

"\n  mode  is  %o  .  "  ,  buf -:>shm_pe  rm.  mode  ); 

"\n  seq  is  %d  .  "  ,  buf ->sltm_perm.  seq  ); 

"\n  key  is  %d . " ,  buf ->shm_pe  rm. key  ); 

"\n  shm_seg8Z  is  %d  or  %x  .  "  ,  buf->shm_segsz ,  buf ->«hm_seg8z  ) 
"\n  shm_reg  is  a  structure  incompletely  defined  in  region. hi" 
"\n  shm_lpid  is  %d.",  buf ->shm_ lp i d  ); 

"\n  shm_cpid  is  %d  . "  ,  bu f ->shm_cp i d  ); 

"\n  shm_nattch  is  %d  .  "  ,  buf - >shm_na t t ch  ); 

"\n  shm_cnattch  is  %d  .  "  ,  buf ->shm_cnat t ch  ); 

"\n  shm_atime  is  %d  .  "  ,  buf ->shm_a t ime  ); 

"\n  shm_dtime  is  %d  .  "  ,  buf ->sltm_dt  ime  ); 

"\n  slim_ctime  is  %d  .  "  ,  buf ->shm_segsz  ); 


I  /*  write  struct!)  */ 
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